CI Linter: List of potential CI config problems to generate warnings for.
Related to #219431 (closed)
CI Linter Alerts
This is a list of potential CI config issues that I think could be worth generating warnings for. These are my own ideas that I believe could be problematic and deserve warnings. These all pass linting (I think), but likely don't give a desired result. Split out from #219431 (comment 367097310).
Deprecation warnings
Warning: The keyword [keyword] is deprecated and [will be removed in GitLab version XX.x](issue link).
Warning: The keyword [keyword] is deprecated and [will be removed in GitLab version XX.x](issue link). Update the pipeline configuration to use [new-keyword](docs-link) before then.
Likely bad config warnings
Some of these I think we can test for, but some may not be easily testable.
-
Warning: Job [job] has "rules" clause(s) that will never be evaluated. [Troubleshooting link](link)
Example:
job: rules: - if: '$CI_PIPELINE_SOURCE == "push"' - if: '$CI_PIPELINE_SOURCE != "push"' - if: '$CI_PIPELINE_SOURCE == "schedules"' # This will never be reached/evaluated, as one of the previous rules will always be true.
-
Warning: Job [job] has "rules" clause(s) that will never be used due to "workflow: rules" configuration. [Troubleshooting link](link)
Example:
workflow: rules: - if: '$CI_PIPELINE_SOURCE == "push"' job: rules: - if: '$CI_PIPELINE_SOURCE == "push"' - if: '$CI_PIPELINE_SOURCE == "schedules"' # This will never be used, as the workflow rules blocks it. when: manual
-
Warning: Job [job] will never run, due to "rules" configuration. [Troubleshooting link](link)
Example 1:
job: # This job will never run, in *any* situation. rules: - if: '$CI_PIPELINE_SOURCE == "push"' when: never
Example 2:
job: # This job will never run, in *any* situation. rules: - when: never
-
Warning: Job [job] will never run, due to mismatch between "rules" and "workflow: rules". [Troubleshooting link](link)
Example:
workflow: rules: - if: '$CI_PIPELINE_SOURCE == "push"' job: rules: - if: '$CI_PIPELINE_SOURCE == "schedules"' # This job will never run, in *any* situation.
-
Warning: Job [job] may allow multiple pipelines to run for a single action, due to "rules: when" clause with no "workflow: rules". [Troubleshooting link](link)
Example 1:
job: rules: - if: '$CI_PIPELINE_SOURCE == "schedules"' when: never - when: always # This is guaranteed to cause duplicated pipelines when an MR is created (without properly configured workflow rules)
Example 2:
job: rules: - when: always # This is guaranteed to cause duplicated pipelines when an MR is created (without properly configured workflow rules)
Alerts at the Tip/Suggestion level
I'm listing these separately at a lower warning level, because we can't be sure that these examples will cause configuration problems. All of these examples could be completely acceptable uses, resulting in exactly the behavior the user wants.
Note the difference in the links as well. These would link to normal docs, not troubleshooting docs:
-
Tip: Job(s) use "rules" without "workflow: rules" defined for the pipeline. It is recommended that you always combine "rules" with "workflow: rules". [Documentation link](link)
-
Tip: Some Job(s) use "rules" while other job(s) use "only/except". It is recommended that you avoid mixing these keywords in the same pipeline. [Documentation link](link)
-
Tip: Job(s) use "rules" without "workflow: rules" defined for the pipeline. It is recommended that you always combine "rules" with "workflow: rules". [Documentation link](link)
-
Tip: Job(s) "rules" use "when: manual" without defining "allow_failure:". It is recommended that you always combine "when: manual" job "rules" with "allow_failure: true" or "allow_failure: false". [Documentation link](link)
Things that I think should be considered full CI failing errors already
-
Error: Job [job] "rules" have clauses after a "when:" clause. [Troubleshooting link](link)
Example that passes CI Lint, but probably shouldn't. We'll probably have to add this as a warning to start, as it could be a breaking change if anyone accidentally did this, and it's hidden in a big complicated pipeline):
job: rules: - when: manual - if: '$CI_PIPELINE_SOURCE == "schedules"' # This rule will never be reached. A standalone "when" should always be the last item, when used.
-
Error: Job [job2]
needs[job1], but they will not run in the same pipeline because their
rulesclauses do not match.
job1: stage: build rules: - if: '$CI_PIPELINE_SOURCE == "schedule"' job2: stage: test needs: - job1 rules: - if: '$CI_PIPELINE_SOURCE == "push"'