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 aboveMR 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 integer10
, duration10s
, URIscheme://user:passwd@host:port
may require quotation or other special handling when rendered in a template and written to a configuration file.
Test plan
manual
job is not triggered
Validate partial pipeline when 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.
manual
job is triggered
Validate full pipeline when 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.