GitLab CI Guide — MyAdminDesk

This is an original planning guide. It is not a vendor manual, an official standard, or legal advice. Example addresses use documentation ranges. Review every command before you paste it.

One file in GitLab CI

GitLab CI in this window is one pipeline file a person can review. The file is .gitlab-ci.yml, or a local include you can open from that file without a treasure hunt. The generators can draft a container build, a Kubernetes deploy, or a Terraform plan and apply. You draft one of those, not all three. Nothing here connects to the forge.

The first job tests or plans. It cannot apply and it cannot deploy. Apply and deploy are later jobs, protected, and manual until a plan job has been boring. A green first run is not permission to touch production.

Protected variables stay on protected branches. A feature branch does not receive them. prompt-for-this in a sample is the gap. A real token in the yaml is a token you rotate and remove.

The job token is not a cloud administrator. A cloud login, later, uses a narrow identity you can revoke. The identity is a workload identity with the small policy from the IAM guide. It is not your personal key and not an owner role.

A plan job first, on a branch you named

Name the repository and the branch. Draft one pipeline. Read every step. If a step deploys, delete it from this first file or gate it so this branch cannot reach it. The picture from the CI/CD guide still applies: check, plan, stop.

Write the stage name so plan is a stage and deploy is absent. A manual job that is not protected is still a job a fork might reach. Read the rules.

Search the file for keys, passwords, and kubeconfigs. There should be none. The secret names may appear as references. The values do not. A registry login uses the platform store.

The Kubernetes deploy draft and the Terraform apply draft wait even if the generator can write them today. Pick build, or pick plan. The other two files are later tickets. Production is not the cluster and not the account in this file.

# GitLab CI note. One file. One job that cannot apply.
# The file is .gitlab-ci.yml, or a local include you can open from that file without a treasure hunt.
# Secrets come from the platform store.
# No personal cloud key. No owner role.
# prompt-for-this is not a token.
# Production is not the target of the first run.

A change you can finish

Enabling the plan or test job on the named branch is the later change. Deploy stays off.

Rollback is the previous pipeline file. You do not roll back a bad file by changing production to match it.

Name the repository and the branch.
Draft one job that tests or plans.
Remove deploy and apply from that first file.
Point secrets at the store.
Confirm the identity is not an owner and not a person.
Search the file for tokens.
Leave the other two generators for later tickets.

Mistakes that outlive the command

GitLab CI fails in the same few ways. Each one looks finished on the day you type it. The list is here so the ticket can forbid them before the window, not so you can recognise them in an incident review.

Three generators committed in one hour.
The first job deploying to production.
A personal access key in the yaml.
An owner or administrator role on the job.
A kubeconfig committed beside the pipeline.
Apply with no manual gate.
A secret value instead of a reference.
The wrong branch protected, or none.
A protected variable available to every branch, or a personal token in the yaml.
Editing production because the job failed.
Calling a green check a release.

Decisions to write down before the window

One decision for GitLab CI: One file is in the ticket. The branch is named. The first job cannot deploy. Secrets are references. No token is in the file. The identity is a workload identity. The identity is not an owner. Production is not the target. The other generators wait. A manual gate exists before any later apply. Protected variables are limited to protected branches. And a second person can point at the stop.

The hour you stop

Write the account, the project or subscription, the region, and the clock time before you change anything for GitLab CI. If this account is serving people and you do not have a way back, this hour is a plan. A plan you can read tomorrow is a success. A change you cannot undo is not.

Use a lab account, a lab project, or a lab subscription you administer. You do not point a CLI, a pipeline, or a browser tool at an account you do not run. The tools on this site run in the browser. They draft text. They do not log in, and they do not scan.

prompt-for-this is a reminder that a secret is missing. It is not an access key, a token, a password, or a kubeconfig you save. The real secret stays in the password store or the platform's secret store. If a file, a log, a ticket, or a pipeline still contains a live secret, stop and rotate it. Then delete the copy.

One change. A network, a virtual machine, a policy, and a pipeline do not share a window. If two things move and the outcome is wrong, you will not know which one did it. The rollback is the previous file, the previous plan, or the resource you can delete because it was only a lab.

A second person reads the scope aloud: which account, which region, which name. If they cannot find it in the ticket, the ticket is not ready. Silence is not agreement.

Documentation addresses stay in the note. 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and 2001:db8::/32 are not prefixes you type into a production network. example.com is not your zone. A generated file that opens 0.0.0.0/0 is a file you edit before it is applied. A source you can name is the rule you keep.

Do not apply a draft you have not read. A cost estimate, a policy, a manifest, and a Terraform plan are reading material. Apply, a resize of a live machine, and a delete of a bucket are later decisions with their own proof. Read the names. Then decide.

Keep the previous file. A generator draft is not the previous file. The previous file is what you put back if the new one is wrong. You practised the path back, including the serial console or a second admin, before you changed a network or a lockout setting.

If a step fails twice, stop. The failure is the result. Adding a command from a forum beside a half-applied stack produces an account nobody can explain. Rebuild the lab from the copy you kept.

When the checks pass, the next account waits until someone else can repeat the proof from the notes. GitLab CI is done for this window when the proof is written, not when a CLI printed a success line.

This page is a planning guide. It is not a vendor manual, not an official standard, not legal advice, and not an audit opinion. If an auditor must see the decision, they see the ticket and the evidence, not this paragraph.

Hand the finished note to the neighbouring guide that owns the next step, and leave this account alone until that guide has its own window.

GitLab CI checks before the job is enabled

Confirm this before you call the change done: The file and the branch are in the ticket. A search found no token. The first job plans or tests only. The identity is not an owner. Production is not named as the target. A second person read the stop. The repository is one you administer. The plan stage has no deploy keyword you meant to save for later. The hostname in the prompt matches the hostname in the ticket for GitLab CI. The result line includes the time and the person, not only the command. You can point at the rollback value without searching a chat history. And done is a sentence a second person can repeat: the proof for GitLab CI happened, and the next host is not started early. If one of those fails, stop.

Tools for this guide

These tools run in the browser on this site. They do not log into your machines.

Guides in this cluster

These supporting pages belong to this pillar.