I’m using Snyk security checks with my project and noticed a weird behaviour when ‘Enable merged results pipelines’ is enabled and rules are defined in the gitlab-ci.yml file
If there are no rules defined in the gitlab-ci.yml file, the external security check jobs for Snyk are running nicely on the same pipeline as the rest of the jobs defined in gitlab-ci.yml file. If I just add the
rules section in the .yml file, without actually defining any rules, and commit this change, it immediately starts to spawn separate pipelines for the Snyk jobs.
The first two commits that were pushed had a gitlab-ci.yml file without any rules defined, and as seen in the first attachment the Snyk jobs are running on the same pipeline as the rest of the jobs defined in the yml file.
This shows what pipelines get spawned with just a simple ‘rules:’ added to the gitlab-ci.yml file.
Also noticed that in the first situation, the ‘merged results’ tag was not visible on the pipeline, and in the second it was.
So the question is really what is the relationship between defining rules in the gitlab-ci.yml file, merged results pipeline and external jobs?
Nobody here can see those two links that you provided because they are in the Paid Gitlab Support system. Since you have paid support, and have opened an issue there, it doesn’t really make sense to post about it here since GItlab support will answer your query quicker.
If you wish for anyone here to help, you will have to post that information here separately because we cannot see it and therefore cannot help.
Thank you for the reply, I’m on a paid trial for now, and support is not available for trials (tried to open a ticket, that’s how I learned).
Attached the screenshots here, if that helps.
Are you able to share the contents of the .gitlab-ci.yml file so that we can see how it’s put together?
Sure, it’s just the boilerplate that gets autogenerated by Gitlab + ‘rules’ to test the pipeline behaviour.
stages: # List of stages for jobs, and their order of execution
build-job: # This job runs in the build stage, which runs first.
- echo "Compiling the code..."
- echo "Compile complete."
unit-test-job: # This job runs in the test stage.
stage: test # It only starts when the job in the build stage completes successfully.
- echo "Running unit tests... This will take about 60 seconds."
- sleep 60
- echo "Code coverage is 90%"
lint-test-job: # This job also runs in the test stage.
stage: test # It can run at the same time as unit-test-job (in parallel).
- echo "Linting code... This will take about 10 seconds."
- sleep 10
- echo "No lint issues found."
deploy-job: # This job runs in the deploy stage.
stage: deploy # It only runs when *both* jobs in the test stage complete successfully.
- echo "Deploying application..."
- echo "Application successfully deployed."
The issue can be easily reproduced by anyone who has a paid license, the ‘Merged results pipeline enabled’ feature is not available for free users. I don’t, so I started a free trial.
- Create a repo with a package.json file that has some dependencies for Snyk to test
- Create a free Snyk account and login
- Connect Gitlab to Snyk from the Snyk UI (quite easy to do)
- Go back to Gitlab and generate a gitlab-ci.yml file or just use the one above. If the file contains rules or any other job that contains rules, the behaviour will reproduce
- Create a branch and make some random changes, like updating a readme file
- Open a MR. Snyk will receive a webhook event and try to run security scans on the commit.
If you keep pushing new commits to the branch that has the MR open, the issue will reproduce every time. Also, disabling merged results pipelines and pushing new changes on the branch above will have jobs running on a single pipeline, as expected.
It seems to me it’s this combination of rules + merged results + external jobs that’s somehow now working and I’m looking to understand if the issue is on Gitlab’s end or not.
I think that following the directions here about switching from branch to to merge request pipelines will resolve this.
I hope this helps!
-James H, GitLab Product Manager, Analyze:Product Analytics
Thank you James, that was helpful.