CI pipeline displayed for Git objects are incorrect when there are multiple pipelines
Summary
When a commit has both a commit pipeline and other pipelines or a tag has multiple pipelines, it will show the latest pipeline, even if this is not the corresponding pipeline for the commit or tag
Current status: This is a bug grouppipeline execution will investigate. The next step is to determine if a choice was made to always equate pipelines by commit only or if it is a bug and there should be a different pipeline for two tags with the same commit.
Steps to reproduce
For commit subbug:
- Setup commit pipeline and schedule pipeline to build from the same branch
- Create a commit on the branch (should trigger commit pipeline)
- Wait for scheduled pipeline to run
- View pipeline associated with latest commit on repo main page or pipeline associated with any commit on
commit
page
For tag subbug:
- Setup tag pipeline
- Create a tag (should trigger tag pipeline)
- Create another tag from the same commit (should trigger another tag pipeline)
- View pipeline associated with first tag on
tags
page
Example Project
https://gitlab.com/Woodz1/gitlab-bug-repros
What is the current bug behavior?
CI pipeline link and status is for latest pipeline, even if the latest pipeline is not the pipeline triggered by the commit or tag shown
What is the expected correct behavior?
CI pipeline link and status is for pipeline triggered by the commit or tag shown
Relevant logs and/or screenshots
The build status icon and link are to the scheduled pipeline https://gitlab.com/Woodz1/gitlab-bug-repros/-/pipelines/648518932, not the commit pipeline https://gitlab.com/Woodz1/gitlab-bug-repros/-/pipelines/647702954
For tags, I created dummy_tag
from the same commit as release/v1.0.2
. Now it looks like release/v1.0.2
tag pipeline is running, even though this is not the case. The status icon and link for tag release/v1.0.2
is for tag pipeline for dummy_tag
(https://gitlab.com/Woodz1/gitlab-bug-repros/-/pipelines/648566989), not tag pipeline for release/v1.0.2
(https://gitlab.com/Woodz1/gitlab-bug-repros/-/pipelines/647702954)
Output of checks
This bug happens on GitLab.com
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)
Possible fixes
I think that there is an assumption that looking up a pipeline should be by commit, which is incorrect. I think we should look up pipeline by GitLab object (e.g. commit, tag or schedule) depending on the object that is currently being viewed