Pipeline badges only reflect "commit" pipelines. should have separate pipeline badges for different pipeline triggers
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Problem to solve
Currently pipeline badges are only updated by pipelines that are triggered by a "commit". There are a number of use cases where this is not appropriate. (For instance, a project where pipelines are only run in response to merge requests, or tags, or by schedules).
As a project owner, I want to be able to put a pipeline badge in my /README.md that reflects the success of the most recent merge_request pipeline.
(In another project, I run pipelines from a schedule; again, I want to put a pipeline badge in my /README.md that indicates the success of the most recent scheduled pipeline.
Intended users
- Project owner
Further details
Comment from a related issue
I think that the main problem here is that tags are not associated with branches. Another concern is that you can have completely different pipeline for a tag, even if this is created for SHA that exists on a branch.
Proposal
- I think this can only be solved by adding a component to the badge path.
My initial proposal was going to be to replace https://gitlab.com///badges//pipeline.svg with https://gitlab.com///badges//pipeline/.svg where trigger might be one of "commit", "schedule", "merge_request", "tag" , but looking at the move from "only/except" to "rules in gitlab-ci.yml suggests to me this lacks the flexibility that "rules" would need.
So, I think instead, that the replacement url should be https://gitlab.com///badges//pipeline/<job_name>.svg where job_name is the name given to the job in .gitlab-ci.yml .
For backwards compatibility, the existing url would need to continue to be supported as well.
Permissions and Security
This doesn't require any different permissions/security model from the existing behaviour, nor does it require any significant change to UI / API or other access methods.
Documentation
This would require change to the documentation in https://docs.gitlab.com/ee/ci/pipelines/settings.html
Availability & Testing
What does success look like, and how can we measure that?
Success is that I am able to put a pipeline badge in my project's README.md that indicates the success of the most recent pipeline triggered by a .gitlab-ci.yml job that is only run on merge_requests.