CI: Make review app jobs manual for Merge Request pipelines

What does this MR do?

CI: Make review app jobs manual

Adds a stage and job marked as manual before the jobs related to Review Apps start. This has some benefits:

• Reduces load on our CI clusters by only creating Review Apps intentionally once the changeset is ready to be tested in a live environment.
• Multiple pipelines are less likely to influence the same Review Apps because they will not be running simultaneously as often.
• If someone pushes a docs-only change, review apps will not be automatically deployed, meaning we save on resources. This gives us an opportunity to redirect them to a new merge request with the proper branch naming strategy for docs-only changes.

We have been using this approach in the Operator project for over two years with gitlab-org/cloud-native/gitlab-operator!213 (merged). This has been working well for the reasons listed above.

Note that the CI setting Pipelines must succeed should be enabled. This ensures that a full pipeline must still be run before a Merge Request can be merged.

Related issues

Related to gitlab-org/distribution&26.

Author checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion.

Required

• Merge Request Title and Description are up to date, accurate, and descriptive
• MR targeting the appropriate branch
• MR has a green pipeline on GitLab.com
• When ready for review, follow the instructions in the "Reviewer Roulette" section of the Danger Bot MR comment, as per the Distribution experimental MR workflow
• Pipelines must succeed setting should be enabled (screenshot below of current configuration). If we choose not to do this, we need to really enforce the checkmark item above MR has a green pipeline on GitLab.com to ensure a full pipeline has run before merging.

For merge requests from forks, consider the following options for Danger to work properly:

• Consider using our community forks instead of forking your own project. These community forks have the GitLab API token preconfigured.
• Alternatively, see our documentation on configuring Danger for personal forks.

Expected (please provide an explanation if not completing)

• Test plan indicating conditions for success has been posted and passes
• Documentation created/updated
• Tests added/updated
• Integration tests added to GitLab QA
• Equivalent MR/issue for omnibus-gitlab opened
• Equivalent MR/issue for Gitlab Operator project opened (see Operator documentation on impact of Charts changes) -> we already do this in Operator CI
• Validate potential values for new configuration settings. Formats such as integer 10, duration 10s, URI scheme://user:passwd@host:port may require quotation or other special handling when rendered in a template and written to a configuration file.

Test plan

Validate partial pipeline when manual job is not triggered

In https://gitlab.com/gitlab-org/charts/gitlab/-/pipelines/1168504506, you can see that the pipeline paused at the new manual job.

Note that specs_without_cluster is able to proceed because it needs lint_package, which allows it to run without waiting on previous stages.

Validate full pipeline when manual job is triggered

In https://gitlab.com/gitlab-org/charts/gitlab/-/pipelines/1168542707, I clicked "Run" on the manual job and the rest of the pipeline proceeded and passed.