Support nested GitLab subgroups for pipeline badge

[ProfessorManhattan]

Are you experiencing an issue with...

• shields.io
• My own instance
• badge-maker NPM package

🪲 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

[chris48s]

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.

[ProfessorManhattan]

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

[chris48s]

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

	static route = {
	base: 'gitlab/pipeline',
	pattern: ':user/:repo/:branch+',
	queryParamSchema,
	}

and

Convert branch to a queryParam

shields/services/gitlab/gitlab-pipeline-status.service.js

Lines 14 to 16 in 3d203e7

	const queryParamSchema = Joi.object({
	gitlab_url: optionalUrl,
	}).required()

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 one
Move 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

	const GitlabPipelineStatusRedirector = redirector({
	category: 'build',
	route: {
	base: 'gitlab/pipeline',
	pattern: ':user/:repo',
	},
	transformPath: ({ user, repo }) => `/gitlab/pipeline/${user}/${repo}/master`,
	dateAdded: new Date('2020-07-12'),
	})

to redirect existing calls to the old route (retaining the assumption that only branch can have slashes in it so we don't break existing badge URLs

Annoyingly, the gitlab coverage badge is going to have the same issue that needs fixing using the same process.
This one is super-annoying because all of our coverage badges are /something/coverage and I can't really think of a good name to move this to. Maybe code-coverage?

[calebcartwright]

I think the way to do it would be to take the existing route

Agreed, that sounds like a good approach and one I believe we've taken in similar situations previously

Move the base to something like gitlab/pipelines or gitlab/pipeline-status

I'd vote for pipeline-status, seems like it'd align well with other routes

This one is super-annoying because all of our coverage badges are /something/coverage and I can't really think of a good name to move this to. Maybe code-coverage

nuts. that is a challenging one. i think code-coverage will work fine, and maybe we even consider adding an inline comment on the route to the effect of "don't copy this particular route pattern" since this is more of an exception than the rule/standard operating procedure

[Kage-Yami]

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 main and develop. So if that's the issue, then I'll look at creating a separate ticket for Lines of Code branches.

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 (%252F being what the wizard generated if I entered a literal %2F in an attempt to pre-encode the slash, similar to what is required for GitLab's APIs):

[chris48s]

With Tokei, the situation is different:

1. The upstream doesn't support this either https://tokei.rs/b1/gitlab/isekai/train-valley-2-modding/AutoHideCompletedLevels is a 404 so I think that's an issue for the upstream.
2. If the upstream service did support it, we could enable this by changing our route from :provider/:user/:repo to :provider/:user/:repo+ because there's no branch param in the route for tokei.

GitLab pipelines is a unique problem here because there are two route params that could possibly have a slash in them.

[ProfessorManhattan]

There are also repo IDs provided on each repository page on GitLab

[calebcartwright]

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 path works - https://gitlab.com/gitlab-org/gitlab/badges/master/pipeline.svg

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.