CI: Make `master`/`stable` pipeline Review Apps consistent with merge request pipelines
What does this MR do?
Implements the changes discussed in #5347 (closed).
Related issues
Closes #5347 (closed)
Closes #5334 (closed)
Closes #5296 (closed)
Closes #5287 (closed)
Impacts
For developers
- Feel more comfortable pushing multiple commits in close succession without worrying about overloading CI or causing conflicts in the Review App environments
- Worry less about pushing docs-only changes when the branch naming rule hasn't been followed
- Have more confidence in the changeset knowing tests that the same tests that passed in your MR pipeline will run in the
master
/stable
pipelines
General
- No more long-lived
production
environments - Environments for Merge Request,
stable
, andmaster
pipelines are isolated per-commit - Environments for Merge Request,
stable
, andmaster
pipelines are shortened from 2 days to 2 hours - We no longer need
resource_groups
to prevent multiple pipelines from affecting the same environment -
stop_review
jobs first try to check out the current branch instead of always checking outmaster
first
To do after merge
CI: Clean up resources related to "production" ... (#5370 - closed)
Test plan
While we can't fully test this until we've merged to master
/stable
, we should be 'safer' than usual now that these jobs are used the same way there as they are in this MR's CI.
-
Pipeline editor: Visualize looks correct -
Pipeline editor: Validate passes
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
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) -
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.
Edited by Mitchell Nielsen