-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support nested GitLab subgroups for pipeline badge #6427
Comments
Hi thanks for raising this. The issue here is that we're reading this as
whereas really it is
I'm don't think we could fix this with the current URL schema given we need to split the branch name off from the user/repo to make the upstream call but both the user/repo and branch name can both contain an arbitrary number of slashes - we don't know where to make the cut. I think we'd have to move it to a new route and set up a redirect for legacy users that makes the current assumption. |
How should I go about creating a PR for this?
…On Wed, May 5, 2021 at 3:10 PM chris48s ***@***.***> wrote:
Hi thanks for raising this. The issue here is that we're reading this as
- user/repo: megabyte-labs/dockerfile
- branch: ci-pipeline/ansible-lint/master
whereas really it is
- user/repo: megabyte-labs/dockerfile/ci-pipeline/ansible-lint
- branch: master
I'm don't think we could fix this with the current URL schema given we
need to split the branch name off from the user/repo to make the upstream
call but both the user/repo and branch name can both contain an arbitrary
number of slashes - we don't know where to make the cut. I think we'd have
to move it to a new route and set up a redirect for legacy users that makes
the current assumption.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#6427 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AOJRHXIYL7TWRYZVFQLHLZLTMGJ3BANCNFSM433KIKXQ>
.
--
Regards,
Brian Zalewski
(412) 345-3338
|
I think the way to do it would be to take the existing route shields/services/gitlab/gitlab-pipeline-status.service.js Lines 43 to 47 in 3d203e7
Convert branch to a shields/services/gitlab/gitlab-pipeline-status.service.js Lines 14 to 16 in 3d203e7
Merge user/repo into a single :userRepo+ param (which can just be passed upstream as a block). We can only have one param with a slash in it and it has to be the last oneMove the base to something like gitlab/pipelines or gitlab/pipeline-status Update the code/examples/tests for the new routes Create another redirector route like shields/services/gitlab/gitlab-pipeline-status.service.js Lines 92 to 100 in 3d203e7
Annoyingly, the gitlab coverage badge is going to have the same issue that needs fixing using the same process. |
Agreed, that sounds like a good approach and one I believe we've taken in similar situations previously
I'd vote for
nuts. that is a challenging one. i think |
I'm guessing this issue also applies to other badges... I think I'm experiencing the same issue with the "Lines of Code" badge - of course, I don't know if the shortcoming is part of Shields.io, or Tokei[.rs] (also not sure if Shields.io self-hosts the library or not). The example repository is here: https://gitlab.com/isekai/train-valley-2-modding/AutoHideCompletedLevels ... as I was writing this, I realised that there doesn't seem to be a way to specify the branch for Lines of Code... so that might be the actual problem (I have no idea); my only branches are For both the Pipeline Status and Lines of Code badges, I tried a couple of different options for the project path; some result in the SVG being generated successfully, but with no data, others fail to generate the SVG entirely ( |
With Tokei, the situation is different:
GitLab pipelines is a unique problem here because there are two route params that could possibly have a slash in them. |
There are also repo IDs provided on each repository page on GitLab |
There may actually be some additional layers of complexity here. We currently retrieve the pipeline status by scraping GitLab's own pipeline status badge. This works fine with a project path, but does not seem to honor the project id: https://gitlab.com/gitlab-org/gitlab project id does not - https://gitlab.com/278964/badges/master/pipeline.svg As such I think that so long as we're utilizing GitLab's status badges, using the id is not a viable option. Switching from scraping the upstream svg's to utilizing the Pipeline API might be tricky too, as the API only really supports a listing of all pipelines or requires the numeric pipeline id to be provided as a route parameter in order to get the status for a specific pipeline. Perhaps it'd be possible for us to continue to have a required ref in our route so we could potentially use with a combination of other upstream params to find the "right" pipeline via either of those upstream endpoints, but that seems like it has a lot more challenges to solve. I agree with Chris that the best course of action tactically, and perhaps even strategically, is for us to switch over to an updated route with a corresponding redirector to prevent breaking existing badges. |
Are you experiencing an issue with...
🪲 Description
For the GitLab pipeline status, shields.io does not seem to support subgroups. Some of my repositories are in multiple levels of subgroups.
🔗 Link to the badge
https://img.shields.io/gitlab/pipeline/megabyte-labs/dockerfile/ci-pipeline/ansible-lint/master?style=for-the-badge
And here is the URL I'm trying to make a badge for:
https://gitlab.com/megabyte-labs/dockerfile/ci-pipeline/ansible-lint
The text was updated successfully, but these errors were encountered: