Read the config and answer what runs

Goal

.gitlab-ci.yml is not a program but a declaration. So it is not "you'll know by running it" but you must be able to answer by reading it. Nearly every incident in which a pipeline runs differently from expectations comes from misreading this file.

Here, you produce answers by looking only at the configuration, without GitLab.

Materials

/opt/lab/glci/pipeline.yml   잡 다섯 개짜리 파이프라인
/opt/lab/glci/broken.yml     문법은 맞는데 뜻이 틀린 곳이 네 군데

mkdir -p /root/glci && cp /opt/lab/glci/* /root/glci/ && cd /root/glci

What to leave

01-jobs.txt     잡과 템플릿
02-vars.txt     같은 변수의 세 값
03-rules.txt    상황마다 도는 잡
04-broken.txt   틀린 네 군데와 고치는 법
fixed.yml       고친 파일
check.py        같은 실수를 다시 막는 검사
07-notes.md     왜 그런지

What is a job and what is not

In pipeline.yml, write in 01-jobs.txt how many real jobs there are and what their names are, and add one line on why .base is not a job.

An item whose name starts with a dot is a hidden template, so it does not run. It is only brought in with extends.

Reserved words such as stages and variables are not jobs either. There are five jobs.

Three variables with the same name

RETRIES is in three places. Write in 02-vars.txt what value is actually used in each of build, unit, and lint, and add one line on why that value wins.

The global variables is the weakest, the template (.base) comes next, and the job's own variables is the strongest.

build and unit only inherit .base, and lint sets its own value separately.

What runs when

Write in 03-rules.txt which jobs run in each of three situations: a push to the main branch, a merge request, and a tag. Separate each situation with a line that starts with its word (main, 머지, 태그; the last two are the Korean words for merge and tag).

rules looks from the top and stops at the first match. If nothing matches, that job does not run.

A last line with only when: never means "otherwise it does not run".

deploy-prod is when: manual on a tag, so it appears in the pipeline but runs only when a person presses it. Count that as "runs" too, but write that it is manual.

Where the syntax is right but the meaning is wrong

Find the four places in broken.yml and write them in 04-broken.txt, along with how to fix each.

All of it reads fine as YAML. What is wrong is GitLab's rules.

• Can a job use only and rules together?
• What happens if you write a stage that is not in stages?
• Can you wait, with needs, for a job in a later stage?
• Is passing files between stages done with cache or with artifacts?

Fix it and leave it as a file

Make fixed.yml, in which you actually fixed the four places. Do not remove a single job.

If you delete a job when fixing, the check passes but the meaning of the pipeline changes. Leave what it was doing as it is and fix only the expression.

For publish, remove the cache and make it receive what build produced, the artifacts. Within the same pipeline, artifacts of earlier stages come down automatically, so write dependencies only when you want to narrow them.

Make a machine block the same mistake

Create check.py so that it blocks broken.yml and passes fixed.yml. It checks the file given as an argument and ends with a non-zero value if there is a problem.

It looks at four things: a stage that is not in stages, only/except coexisting with rules, a needs that waits for a later stage, and trying to pass things between stages with cache.

A check that cannot block is not a check, and a check that also blocks the fixed one is one nobody uses. Confirm both sides with the two files.

To the next person who reads it

Pick four or more of what you saw here and organize them in 07-notes.md. Write not what you did but why it is so.

Think of it as being read by yourself when a pipeline runs differently from expectations. "I looked at rules" does not help, but "rules stops at the first match, so a condition written below is never looked at if the one above matches" does.