gitlab "include:" functionality provides no user warnings/feedback if there is an overriden include
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
Consider users that are leveraging the include: capability (https://docs.gitlab.com/ee/ci/yaml/#include), in order to achieve compartmentalization and re-use.
gitlab-ci.yml files can grow over time.
I've run into this scenario twice now (user error), where I accidentally add a new include to a core gitlab-ci.yml, and it overwrites the previously defined include: statements without any warnings. It can be very easy to not notice, and deliver changes that suddenly cripple some of the jobs in your pipeline.
Would like to propose here that we somehow improve user feedback/debugability for this error case.
Intended users
Developers
Further details
Here's how it SHOULD be done: (A)
include:
- local: '.gitlab-ci_foo.yml'
- project: 'group-foo/my-project'
ref: master
file: '/templates/.gitlab-ci-template.yml'
... etc ...Now imagine that the above (A) is defined somewhere in the gitlab-ci.yml file. If a developer goes in and adds ANOTHER include (B), it will either override the existing (A) (if it comes after), or (B) will not take affect (if it comes before).
i.e. (B)
include:
- local: '.gitlab-ci_bar.yml'When gitlab parses the file for pipeline & job creation, there is NO feedback to the user that they've overridden their own includes.
Proposal
Pre-note: gitlab-ci.yml parse ERRORS are caught in CI lint and the pipeline is rejected entirely. (this is currently clearly shown to the user)
--
TBD (unclear)
- there MAY be back-end logs available to the administrator, but those aren't visible to the end user
- there MAY be existing use cases where blind override is expected
My intention however is to make it clear in the PIPELINE (as a WARNING).
EXAMPLE: https://///pipelines/####
passed Pipeline #### triggered 1 hour ago by (snip)
toggle dummy to retrigger pipeline
7 jobs from <BRANCH_REF> in 3 minutes and 8 seconds (queued for 1 second)
latest
<COMMIT>So there is a "summary". In my scenario, the overridden include is completely lost, so whatever jobs it may have had defined are lost/missing (as such, it is not reasonable to expect something like "XX jobs missing due to duplicate include").
My thought here is to add a "gitlab-ci.yml Parser Warnings" section to the summary.
IF there are parser warnings, list them there with more information.
Something such as:
`gitlab-ci-yml` parsing warnings:
* found duplicate `include:` statements! (lines XXX, YYY, etc)Permissions and Security
READ, on the web UI (to start), as part of pipeline details , not sure if this is useful at the API level
Documentation
https://docs.gitlab.com/ee/ci/yaml/#include https://docs.gitlab.com/ee/ci/yaml/#nested-includes
Arguably ... docs state:
Duplicate includes are considered a configuration error. , which is currently NOT the case :( -- I wish it were
Testing
TBD based on solution
What does success look like, and how can we measure that?
Users that accidentally add an include that overrides any existing includes are notified in an obvious way as soon as a push is made to the gitlab instance and gitlab-ci.yml is parsed.