Frontend: Merge request pipelines appear in projects with any invalid YAML configuration, even if no jobs are configured for Merge Requests
Summary
By making any CI Yaml syntax error, unexpected merge request pipelines are created in my project.
Steps to reproduce
Originally drafted by @marcel.amirault:
Configure a pipeline that blocks MR pipelines:
workflow:
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
when: never
- if: $CI_COMMIT_BRANCH
job:
rules:
- if: $CI_COMMIT_BRANCH
script:
- export
Create an MR for the branch. Push commits to the branch as normal and see branch pipelines appear on the merge request's Pipelines tab:
Push a commit with invalid CI Yaml syntax and see the two invalid pipelines listed in the table:
What is the current behavior?
Merge request pipelines are created and persisted with invalid syntax.
What is the expected correct behavior?
Only the branch pipeline I expected to see should appear with the invalid syntax error message.
Why is this happening?
Under the hood, if a merge request is open from a branch, a push to that branch will always initialize two pipelines, one for the branch and one for the merge request. With a plain, valid, configuration for a couple branch jobs:
- the branch pipeline and its builds get persisted, waiting to be picked up by the runner. Totally standard.
- the merge request pipeline, has no jobs, and so the pipeline is never persisted and it disappears. Initialized but never written to the database.
So we have a problem making this decision for pipelines with invalid configuration syntax. We can't ever know if the merge request pipelines has jobs or not because we can't get far enough in the configuration processing to know what the jobs are. We just have a pipeline with some garbled config, which in any other circumstance we want to persist so the user can see where the problems are.
Possible fixes
This is a difficult problem to solve, because the invalid syntax itself is what prevents us from knowing that any merge request pipeline at all is undesireable. It seems that to address this behavior, we would need to change the paradigm of initializing pipelines before we decide whether or not they are valid and can be saved.
It's possible that this is not an architectural change we are willing to make. In that case, we should take some steps to prevent the display of these pipelines to the user, because even though they exist they were never asked for and mostly serve to clutter up the pipelines tab with duplicate error messaging.