FAQ: A Desk Checkout Is Not the Pipeline Snapshot

I keep hearing one claim in pipeline reviews.
The YAML is open, so the pipeline must be real.
Is a desk checkout the snapshot GitLab will create?

I do not treat those two as the same object.
A worktree can drift minutes after the push.
GitLab builds from a commit plus server config.

Why this myth survives

You can see the files, so they feel authoritative.
A helper can explain every job in that file.
A remote shell can print the same tree.

Then the real pipeline page shows different jobs.
Did the branch move while you were reading?
Did GitLab merge includes you never opened locally?

I flag it when review notes cite only a local tree.
The note assumes disk state equals pipeline state.
That assumption fails before any runner starts.

Questions I ask first

• Did the note cite a SHA, or only a branch name?
• Did anyone open the expanded config after creation?
• Was the ref protected when that job was created?
• Which pipeline source actually created that job list?

What I refuse to pretend

I can use a MonkeyCode free model session to read YAML.
I can use its free server option for a clean shell.
Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Those two options only help me inspect a checkout.
They do not create a pipeline on GitLab.
They do not inject protected CI variables either.

I will not invent model names, quotas, or hardware.
I will not claim a duration or a benchmark.
Access limits belong on the current product page.

Myth one: the opened file is the config

People say the root file is the whole pipeline.
Is that true when the project sets another path?
GitLab allows a custom path for its CI config.

That setting can name a different configuration file.
It can also point at a file in another project.
Your clone can still show a root YAML file.

Includes are merged when GitLab creates the pipeline.
A local include uses files from that same snapshot.
A project include reads another project and ref.

A remote include fetches a URL at creation time.
A template include pulls a template GitLab hosts.
A component include pins a catalog version too.

None of that merge happens inside your editor.
A model summary of one file can miss includes.

The opened file is only a candidate config.
The expanded config on the pipeline is the evidence.
Compare those two before you argue about jobs.

What I check for myth one

• I check the project's custom CI config path setting.
• I list every include line before I trust a summary.
• I compare expanded config against the commit SHA.

Myth two: exports match CI variables

I hear this right after a failed job.
Someone exported the same names on a server.
Does a shell export equal a CI variable?

A shell export lives in that one process.
GitLab injects variables into the created job environment.
The injection depends on scope, not on spelling.

Protected variables show up on protected refs only.
Environment-scoped variables follow that job's environment name only.
Unprotected pipelines do not receive those protected values.

Masked does not mean the job lacks the value.
Masking tries to hide the value in logs.
It is not deletion, and it can fail.

Group, project, and job keys can share one name.
GitLab documents precedence, and that table has grown.
Policy layers arrived after many older blog posts.

Do not memorize a ranked list from memory.
Read the precedence page for your GitLab version.
A missing name on a free server is also data.

That server cannot reveal protected values you lack.
Corrected model: matching names are not matching values.
Source, scope, and protection decide the injected value.

Verify with names only, and never print secrets.
A printed token would prove nothing useful here.
Stop the check if a command might reveal one.

What I check for myth two

• I compare variable names, never copied secret values.
• I note whether the ref was protected at creation.
• I read the current precedence table for this version.

Myth three: a local diff proves changes

This myth breaks skip rules in quiet repos.
People run a local diff and treat it as proof.
Is that rule the same check as your diff?

GitLab evaluates those rules while creating the pipeline.
Branch pipelines and merge request pipelines use different diffs.
A merge request compare uses the target branch.

Your local diff may use a different base commit.
Uncommitted edits never enter that pipeline comparison at all.
A dirty worktree is not a push event.

Scheduled pipelines may have no push diff available.
Tag pipelines can take a different path too.
GitLab documents cases where no file compare exists.

I will not freeze that behavior from an old note.
Check the changes-rule page for your GitLab version.
If the docs and your skip disagree, trust the docs.

Corrected model: changes rules need real pipeline context.
Context means source, ref, and the base SHA.
A local diff is a hint, not a verdict.

What I check for myth three

• I record pipeline source before I argue about skips.
• I record the base SHA GitLab used for the compare.
• I ignore uncommitted files when I judge changes rules.

Myth four: a clean clone is that build

A free server can clone the default branch.
That clone is not automatically the pipeline commit.
Which commit SHA did GitLab actually schedule then?

Pipelines bind to the predefined commit SHA value.
They also store a pipeline source value there.
Ref protection is a separate true or false flag.

A later commit on the branch is a new snapshot.
Rebase, merge, and squash all change that SHA.
File similarity still does not prove pipeline identity.

Protected runners can ignore jobs from unprotected refs.
A green command on an unprotected clone proves little.
It does not prove protected variables were injected.

It also does not prove runner tags matched.
Corrected model: identity is SHA, source, and protection.
Branch tips move, and pipeline snapshots should not.

What I check for myth four

• I match the job SHA to the local HEAD SHA.
• I read CI_PIPELINE_SOURCE from the job, not from memory.
• I read CI_COMMIT_REF_PROTECTED before I assume secrets existed.

Commands that collect evidence

I want evidence I can paste without secrets.
These commands read git state and YAML shape.
They do not call the GitLab API at all.

#!/usr/bin/env bash
# Inspection aid. It does not contact GitLab.
# It prints refs and line hits, not secret values.
set -euo pipefail

repo_head="$(git rev-parse HEAD)"
repo_branch="$(git rev-parse --abbrev-ref HEAD)"
dirty_count="$(git status --porcelain | wc -l | tr -d ' ')"

printf 'head=%s\n' "${repo_head}"
printf 'branch=%s\n' "${repo_branch}"
printf 'dirty_paths=%s\n' "${dirty_count}"

if [[ -f .gitlab-ci.yml ]]; then
  printf 'root_yaml=present\n'
else
  printf 'root_yaml=missing\n'
fi

printf 'include_lines:\n'
grep -nE '^[[:space:]]*include:' .gitlab-ci.yml || true
printf 'component_lines:\n'
grep -nE 'component:' .gitlab-ci.yml || true
printf 'changes_lines:\n'
grep -nE 'changes:' .gitlab-ci.yml || true

I label this script as an unexecuted aid.
I have not used it as a benchmark.
Run it only in the repo you mean to ship.

After that, I copy five fields from GitLab.
I type them myself from the pipeline page.
I do not let a model invent those fields.

pipeline_id:
pipeline_source:
commit_sha:
ref_protected:
expanded_config_matches_worktree:

A proposal YAML, not a receipt

This snippet is a proposal for a safe echo.
I have not executed it as a release job.
It prints identity fields, and it never prints tokens.

# Proposal only. Not a pipeline I ran.
workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_COMMIT_REF_PROTECTED == "true"

show_snapshot_id:
  script:
    - echo "source=${CI_PIPELINE_SOURCE}"
    - echo "sha=${CI_COMMIT_SHA}"
    - echo "protected=${CI_COMMIT_REF_PROTECTED}"

Why echo those three predefined values at all?
They name the snapshot without exposing secret values.
If they disagree with your review notes, stop.

Decision table

Claim I hear	Evidence that counts	Corrected model
The file on disk is the pipeline	Expanded config after creation	The disk file is a candidate
Exported names match CI values	Non-secret names from the job	Scope and protection decide values
A local diff proves changes	Source plus base SHA	Changes rules need GitLab context
A clone equals the build	Commit SHA on the job	Identity is the snapshot
A model note creates jobs	Job list after creation	Explanation is not creation

How I use the free options

I run the probe on a free server when my laptop is dirty.
The clean shell keeps local junk out of the count.
Then I paste the text into a free model session.

I ask only for mismatches in the wording.
I ask it not to guess secret values.
I ask it not to invent a commit SHA.

If the model and the page disagree, I trust the page.
The free server is still not a GitLab runner.
The free model session is still not pipeline creation.

Check current docs before you depend on access.
I will not call any access limit permanent.

A short review workflow

1. I run the probe and save the output.
2. I open the pipeline that reviewers cited.
3. I copy source, SHA, and the protection flag myself.
4. I open expanded config, not only my editor buffer.
5. I compare include lines with the probe hits.
6. I stop immediately if the SHA values differ.
7. I read current docs if changes rules surprise me.
8. I only then talk about the job scripts.

Limits I say out loud

This probe does not expand includes for you.
Remote includes can change between two pipeline runs.
A custom config path stays invisible to the script.

Compliance pipelines can replace your project file entirely.
Protected variables stay hidden from this probe on purpose.
A free model can still misread YAML anchors.

A free server clock is not pipeline time.
The changes-rule notes can change between GitLab versions.
No quota, duration, or hardware claim belongs here.

Who should not use this

Skip this if you need a signed release receipt.
Skip this if compliance config is hidden from you.
Skip this if the real question is runner capacity.

Skip this if you are debugging cache uploads.
Skip this if you wanted a chat to replay a job.
Those failures need a different checklist than this one.

This FAQ only separates a worktree from a snapshot.
It will not prove that a job is correct.
It will not prove that a runner was eligible.

Before you merge

Run the probe in the repo you think you shipped.
Copy the five fields from the real pipeline page.
Ask the model to compare text, not to invent SHAs.

If the SHAs differ, find the commit GitLab built.
If includes differ, open the expanded config next.
That is the fix path I actually trust.

I keep a free session for the reading step only.
The pipeline page remains the source of truth.
Would you ship a claim you cannot tie to a SHA?