rules, workflow, Pipeline Sources, Changes, Conditions, and Dynamic Pipeline Creation: Guided Hands-On Workflow and Core Operations

1. Disposable scenario and preflight

Use a disposable project or a branch such as ch12/rules-lab. The lab changes only synthetic files and CI configuration. It does not register runners, create tokens, deploy environments, or touch registries. If no runner capacity is available, you can still validate configuration, inspect whether GitLab creates a pipeline object, and reason about job inclusion; actual job logs are optional evidence.

2. Create tiny synthetic paths whose state is obvious

mkdir -p app docs
printf 'print("hello")
' > app/main.py
printf '# Guide
' > docs/guide.md
printf 'enabled=true
' > app/feature.flag
git status --short

These files let us distinguish change state from existence state. docs/guide.md can be changed independently, while app/feature.flag can simply exist.

3. Build a deterministic branch/MR workflow

workflow:
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"'
      when: never
    - if: '$CI_COMMIT_BRANCH'
    - if: '$CI_COMMIT_TAG'
    - if: '$CI_PIPELINE_SOURCE == "web"'

stages: [inspect, test]

context_probe:
  stage: inspect
  script:
    - printf 'source=%s
' "$CI_PIPELINE_SOURCE"
    - printf 'sha=%s
' "$CI_COMMIT_SHA"
    - printf 'ref=%s
' "$CI_COMMIT_REF_NAME"
  rules:
    - when: on_success

docs_check:
  stage: test
  script: echo "docs job exists because docs changed"
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      changes:
        - docs/**/*
    - if: '$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH'
      changes:
        - docs/**/*

feature_present:
  stage: test
  script: echo "feature marker exists"
  rules:
    - exists:
        - app/feature.flag

4. Validate and inspect expansion before triggering

Use Build → Pipeline editor or CI Lint. Validate GitLab semantics, not only YAML syntax. Inspect merged configuration if includes are involved. Confirm that the workflow has a deliberate finite set of positive cases rather than an accidental broad fallback.

Write an expected matrix before pushing:

5. Commit the lab and bind evidence to an exact SHA

git switch -c ch12/rules-lab
git add -- .gitlab-ci.yml app/main.py app/feature.flag docs/guide.md
git diff --cached --check
git diff --cached
git commit -m "ch12: add deterministic pipeline rules lab"
BASE_SHA="$(git rev-parse HEAD)"
printf 'base_sha=%s
' "$BASE_SHA"
git push -u origin ch12/rules-lab

In GitLab, record the created pipeline’s source/ref/SHA. If it is a branch pipeline, verify source=push. Do not print the entire environment; the three allowlisted values above are sufficient.

6. Open a disposable MR and prove duplicate suppression

Open an MR from ch12/rules-lab to the default branch. Push one harmless additional commit. With the workflow above, GitLab should create an MR pipeline and suppress the duplicate branch pipeline for the branch push while an MR is open.

printf '
MR note
' >> docs/guide.md
git add -- docs/guide.md
git commit -m "ch12: change docs under open MR"
MR_SHA="$(git rev-parse HEAD)"
git push
printf 'mr_sha=%s
' "$MR_SHA"

Verify independently: the MR pipeline has source merge_request_event, its SHA matches the pushed commit, and there is not a second branch-push pipeline for the same SHA. If you do see both, preserve both IDs before changing anything.

7. Prove changes and exists are different predicates

Now change only app/main.py. In the MR pipeline, docs_check should be absent because no docs path changed relative to the MR target branch. feature_present should still exist because app/feature.flag remains in the repository.

printf '# harmless change
' >> app/main.py
git add -- app/main.py
git commit -m "ch12: app-only change"
APP_SHA="$(git rev-parse HEAD)"
git push

That observation proves why “changed” and “exists” must not be used interchangeably.

8. Intentionally create no pipeline and diagnose the rule

Use a temporary branch rule that denies one clearly named lab branch before the normal branch rule:

workflow:
  rules:
    - if: '$CI_COMMIT_BRANCH == "ch12/no-pipeline"'
      when: never
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
    - if: '$CI_COMMIT_BRANCH' 

Validate it, create/push ch12/no-pipeline, and observe that no pipeline object appears for that push. Diagnose from configuration plus the branch/source context: this is not “no runner,” because a runner is consulted only after a job exists. Restore the normal workflow after capturing evidence.

9. Manual/web pipeline: inspect source before trusting changes

If your role allows a harmless manual run from Build → Pipelines → New pipeline, run against the disposable branch. The source should be web. Do not infer file-delta behavior from the last push. For non-push sources, either avoid changes or use an explicit compare_to when a defined comparison is required.

10. Optional Free dynamic child fixture

This optional example generates a fixed child configuration from reviewed literals. It demonstrates configuration creation without using external/untrusted input.

stages: [generate, child]

generate_child:
  stage: generate
  script:
    - |
      cat > generated-child.yml <<'YAML'
      child_probe:
        script:
          - echo "child_source=$CI_PIPELINE_SOURCE"
          - test "$CI_PIPELINE_SOURCE" = "parent_pipeline"
      YAML
  artifacts:
    paths: [generated-child.yml]

run_child:
  stage: child
  trigger:
    include:
      - artifact: generated-child.yml
        job: generate_child

11. Challenge: choose the control surface

You need expensive integration tests only for MR pipelines when app/** changes. Should you suppress all non-MR pipelines in workflow:rules, or keep branch pipelines for lightweight jobs and put the path/source condition on the expensive job? Justify the answer from project needs. The key is to place a condition at the narrowest layer that matches the policy: whole-pipeline policy belongs in workflow; job-specific policy belongs in job rules.

12. Cleanup and verification

• Restore the intended workflow after the no-pipeline demonstration.
• Close the synthetic MR if you created one and delete only the lab branches after confirming the evidence SHAs remain reachable in your local clone/notes as needed.
• Remove synthetic app/, docs/, and CI changes or delete the disposable project.
• Verify no token, secret, environment deployment, package, or external resource was created.

Knowledge check

Summary

The guided lab proved creation-time causality with before/after evidence: workflow chooses pipeline type, job rules choose job existence, changes and exists answer different questions, and a deliberately absent pipeline is diagnosed before runner concerns enter the model.

Official references

• GitLab Docs — workflow keyword
• GitLab Docs — Specify when jobs run with rules
• GitLab Docs — CI/CD YAML syntax reference
• GitLab Docs — Predefined CI/CD variables
• GitLab Docs — Where variables can be used
• GitLab Docs — Merge request pipelines
• GitLab Docs — Downstream pipelines
• GitLab Docs — Pipeline editor
• GitLab Docs — CI Lint
• GitLab Docs — CI/CD pipelines
• GitLab Docs — Pipelines API
• GitLab Docs — Use CI/CD configuration from other files