How do you see what happens after a change?
Start with the project’s .gitlab-ci.yml file. It describes jobs that run on a runner, the computer executing the job. Separate jobs into stages such as check, package and release so a failed check can stop the next stage.
Open the pipeline result for the proposed change and find the first failing job. Read its result before rerunning. Repeating a check without fixing the bad input can hide what went wrong.
When does a manual release job actually block progress?
Decide whether the manual job is optional or blocking. An optional job can be skipped. Configure a blocking job when later stages must wait for somebody to approve the release.
If approval belongs to specific people, check protected environment access. Protected environments for manual jobs are documented for Premium and Ultimate. A manual button alone does not establish which people can use it.
How much runner time do you get and what can you move?
GitLab.com Free namespaces get 400 compute minutes per month. A namespace is your personal or group area in GitLab. Eligible instance runner jobs use the quota, and the runner’s cost factor changes how quickly it goes down.
Keep the pipeline file in version control and download reports or built files you need later. Job artifacts can expire. Check the artifact access and expiry, and keep a separate record of which revision was approved for release.
How can you prove a release step depends on the right result?
Sketch a check, a package and a manual release for a fictional booking app. Use no runner or deployed project.
- Mark a failed checkWrite “the booking times shown are wrong.” Trace where the package and release stop.
- Name the person who actsOn a separate passing copy, write who could review the result and what they would verify before releasing.