DevOps / Gitlab Interview questions
What is the difference between GitLab CI/CD "rules" and the deprecated "only/except" keywords?
only/except were the original, simpler way to control whether a job runs, based on branch names, tags, or a handful of predefined conditions. rules replaced them as the more expressive, actively supported mechanism and is now the recommended approach; only/except still work but are considered legacy.
| only/except | rules |
| Simple branch/tag/condition matching. | Ordered list of conditions, each with its own if, changes, or exists clause. |
| Cannot easily combine multiple independent conditions. | Can combine branch, variable, and file-change conditions together. |
No per-condition control over when (manual, delayed, always). | Each rule can set its own when behavior. |
| Legacy; still functions but not recommended for new pipelines. | Current recommended keyword going forward. |
deploy: script: ./deploy.sh rules: - if: '$CI_COMMIT_BRANCH == "main"' when: on_success - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: manual - when: never
The example above only runs automatically on main, allows a manual trigger from merge request pipelines, and skips the job in every other case, a level of nuance that only/except alone can't express as cleanly.
Which keyword is the current recommended way to control job execution conditions?
A capability rules has that only/except lacks is:
More Related questions...
