Same name job with conditional import issue
Summary
When doing an import if there is a job with the same name then the yaml should not be valid, however it appears it will always run the task in this case called build that returns "Generic Build"
I have created a public repo to illustrate the issue, I was expecting the build to fail with duplicate yaml job names... but it goes forward... However there are a few strange things..
- The Build defined on the gitlab-ci.yml does not run at all under certain conditions
danielmd3000/conditionalimportissue@f4d01de3
- However under some circumstances the build job does not run at all
danielmd3000/conditionalimportissue@28a708bb
The circunstance is as follows
in .gitlab-ci.yml file there is a build job like:
build: script: - echo "GENERIC BUILD" And in the imported file there is a similar job but with a condition, as such:
build: rules: - if: $PRJ == "A" script: - echo "SPECIFIC BUILD" This results in a pipeline that never has the build job... and if we set PRJ to A at Run pipeline, the job that is added to the pipeline is the job in the gitlab-ci.yml
The behaviour I expected was
PRJ is null in that case the gitlab-ci.yml build job (GENERIC BUILD) would run. However it does not even get added to the pipeline.
PRJ is A in that case the .specificbuild.yml build job (SPECIFIC BUILD) would run. However this job is never able to run. The job that ends up running is the GENERIC BUILD job.
In other words, is it expected that if a job is imported via include that has the same name as the one in a file it is being included in that the importing file will always have precedence?
Should this not be an error similar to when we try to add the same key job to the same file... this seems like a bug to me, since it introduces unpredictability in the pipeline, the expected outcome to be should be an runtime error, similar to the edit time error Map keys must be uniqueYAML(0)
Also it is not clear why the included build job if it has a rules if condition, prevents the generic build job to be included... if the including file should always win then the gitlab-ci.yml
In short the behaviour is not consistent, the rules if in the including file should not affect the inclusion or not of the build job, removing the rules if, makes the including file run.
Steps to reproduce
Remove or add the rules if condition on .specificbuild.yml and run the pipeline.
Example Project
danielmd3000/conditionalimportissue@28a708bb
What is the current bug behavior?
build job is not added to pipeline
What is the expected correct behavior?
build job should not be dependent on another job having a condition.
Also it is not clear why the included build job if it has a rules if condition, prevents the generic build job to be included... if the including file should always win then the gitlab-ci.yml declared build job should always be added. Or an error should be outputted after the import is executed.
In short the behaviour is not consistent, the rules if in the including file should not affect the inclusion or not of the build job, removing the rules if, makes the including file run.
Relevant logs and/or screenshots
Output of checks
Results of GitLab environment info
Expand for output related to GitLab environment info
(For installations with omnibus-gitlab package run and paste the output of: `sudo gitlab-rake gitlab:env:info`) (For installations from source run and paste the output of: `sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)
Results of GitLab application Check
Expand for output related to the GitLab application check
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)(we will only investigate if the tests are passing)