Badge request: Gitlab CI and Gitlab #541

tankerkiller125 · 2015-09-27T20:28:59Z

It would be awesome if Shields supported Gitlab and Gitlab CI. They have a Decent API and it should be 100% feasible.

espadrine · 2015-10-05T10:02:24Z

Thanks for the suggestion! I believe they detail their API here, although I haven't looked into what kind of badges we can provide.

tankerkiller125 · 2015-10-05T14:23:07Z

Unfortantly based on the documentation a authentication key is required no matter what. Would it be possible to get a key that Shields can use? Say for example a Shields account on gitlab just for this purpose?

espadrine · 2015-10-05T14:29:32Z

We use secrets.json for authentication (for instance, we use it with GitHub). As long as it isn't a per-user authentication, it works.

tankerkiller125 · 2015-10-08T14:19:01Z

They only seem to be user specific for private projects (not a suggested thing to badge) internal projects and public projects can be viewed by anyone so long as they have an API key.

ishitatsuyuki · 2016-03-24T12:53:25Z

+1: any plans on this?

moeabdol · 2016-03-26T03:36:37Z

👍

sergeysova · 2016-05-01T11:42:01Z

Gitlab now supports CI badge!

sergeysova · 2016-05-01T11:43:08Z

sergeysova · 2016-05-01T11:43:36Z

Maybe add Gitlab issues count?

gluons · 2017-06-24T08:24:09Z

@lestad But I still prefer Shields badge style. 😅

paulmelnikow · 2017-09-22T20:28:03Z

PR #841 has gone stale and needs work. If anyone would like to adopt it, please do!

sum01 · 2018-06-12T21:56:43Z

The v4 API doesn't require authentication for most things. Unsure if that's what's stalling this or not.

LVMBDV · 2018-06-14T19:37:59Z

I wanted to poke around the API on https://gitlab.com before I began working on this and I must say it's weird. The documentation is lacking and in some cases, misleading (wrong?).

The docs for issue and merge request state that every API call to these functions must be authenticated but I can access them without any authentication on public projects. Try it yourselves:

curl -v 'https://gitlab.com/api/v4/projects/coldnight%2fci-test/issues'
curl -v 'https://gitlab.com/api/v4/projects/coldnight%2fci-test/merge_requests'

This is good for making badges but still, weird documentation.

Also, pipeline status(es) can be accessed only by the project owner, as per its documentation but there is a but. Despite the documentation (again), all commits of a public project can be accessed and the pipeline status of the last commit can be retrieved through the commits API. So we can make a badge for it after all.

Moreover, implementing a user token cycling subsystem like it was done for GitHub would be a security risk as it might allow other users to access private repository data due to the lack of a fine-grained permission system for application tokens (or personal access tokens). I haven't looked much into it but are we sure this is not a problem with private repositories on GitHub as well?

TL;DR We can make it happen but I wish GitLab had better permissions.

P.S. I hope GitLab isn't authenticating me through some black magic without a token. Please try the command above to confirm my findings.

Snuggle · 2018-06-14T21:02:06Z

~ ➜ curl -v 'https://gitlab.com/api/v4/projects/coldnight%2fci-test/issues'
*   Trying 52.167.219.168...
* TCP_NODELAY set
* Connected to gitlab.com (52.167.219.168) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain; CN=gitlab.com
*  start date: May 11 00:00:00 2018 GMT
*  expire date: May 11 23:59:59 2019 GMT
*  subjectAltName: host "gitlab.com" matched cert's "gitlab.com"
*  issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Domain Validation Secure Server CA
*  SSL certificate verify ok.
> GET /api/v4/projects/coldnight%2fci-test/issues HTTP/1.1
> Host: gitlab.com
> User-Agent: curl/7.60.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: nginx
< Date: Thu, 14 Jun 2018 21:00:35 GMT
< Content-Type: application/json
< Content-Length: 7699
< Cache-Control: max-age=0, private, must-revalidate
< Etag: W/"71530dc535d8812ea57aeb5f6d419c91"
< Link: <https://gitlab.com/api/v4/projects/coldnight%2Fci-test/issues?id=coldnight%2Fci-test&order_by=created_at&page=1&per_page=20&sort=desc&state=all>; rel="first", <https://gitlab.com/api/v4/projects/coldnight%2Fci-test/issues?id=coldnight%2Fci-test&order_by=created_at&page=1&per_page=20&sort=desc&state=all>; rel="last"
< Vary: Origin
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
< X-Next-Page: 
< X-Page: 1
< X-Per-Page: 20
< X-Prev-Page: 
< X-Request-Id: 16c93385-31dc-4c40-a829-4e8a68685956
< X-Runtime: 0.188505
< X-Total: 9
< X-Total-Pages: 1
< Strict-Transport-Security: max-age=31536000
< RateLimit-Limit: 600
< RateLimit-Observed: 1
< RateLimit-Remaining: 599
< RateLimit-Reset: 1529010095
< RateLimit-ResetTime: Fri, 14 Jun 2018 21:01:35 GMT
< 
[{"id":11752626,"iid":12,"project_id":5168279,"title":"Epale","description":"Epale","state":"opened","created_at":"2018-06-07T01:37:54.903Z","updated_at":"2018-06-07T01:37:54.903Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":2421176,"name":"Yamel Senih","username":"yamelsenih","state":"active","avatar_url":"https://secure.gravatar.com/avatar/e8270c029a61298fee5373903a889c8f?s=80\u0026d=identicon","web_url":"https://gitlab.com/yamelsenih"},"assignee":null,"user_notes_count":1,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/12","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":10959931,"iid":11,"project_id":5168279,"title":"test issue","description":"il faut changer l'image d'accueil","state":"opened","created_at":"2018-05-22T12:19:21.217Z","updated_at":"2018-05-22T12:21:00.293Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":2327051,"name":"Matthieu Jourdain","username":"mjourdai","state":"active","avatar_url":"https://secure.gravatar.com/avatar/4c59cb12bccffb8f6459e423f1607b4f?s=80\u0026d=identicon","web_url":"https://gitlab.com/mjourdai"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/11","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":10299621,"iid":7,"project_id":5168279,"title":"SuperR(@superr)","description":"hello","state":"opened","created_at":"2018-04-13T08:08:24.121Z","updated_at":"2018-04-13T08:08:24.121Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":2209888,"name":"huangzhiping","username":"yeren86125","state":"active","avatar_url":"https://assets.gitlab-static.net/uploads/-/system/user/avatar/2209888/avatar.png","web_url":"https://gitlab.com/yeren86125"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/7","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":10298307,"iid":6,"project_id":5168279,"title":"superr","description":"hello","state":"closed","created_at":"2018-04-13T06:35:12.496Z","updated_at":"2018-04-13T06:55:47.239Z","closed_at":"2018-04-13T06:53:57.240Z","closed_by":{"id":2209888,"name":"huangzhiping","username":"yeren86125","state":"active","avatar_url":"https://assets.gitlab-static.net/uploads/-/system/user/avatar/2209888/avatar.png","web_url":"https://gitlab.com/yeren86125"},"labels":[],"milestone":null,"assignees":[],"author":{"id":2209888,"name":"huangzhiping","username":"yeren86125","state":"active","avatar_url":"https://assets.gitlab-static.net/uploads/-/system/user/avatar/2209888/avatar.png","web_url":"https://gitlab.com/yeren86125"},"assignee":null,"user_notes_count":2,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/6","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":9712207,"iid":5,"project_id":5168279,"title":"My first sample issue","description":"Steps to repro:\n\nThis is my first sample issue.Please ingnore ![4hit_URL]\n(/uploads/6c5962b228919a9fe8f1bbd088c41c98/4hit_URL.jpg)","state":"closed","created_at":"2018-03-14T05:28:48.887Z","updated_at":"2018-03-14T05:36:17.614Z","closed_at":"2018-03-14T05:36:17.609Z","closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":2105368,"name":"Prabhu","username":"prabhuamtex","state":"active","avatar_url":"https://secure.gravatar.com/avatar/5f6b6125e41f4053da8839c780d2ae11?s=80\u0026d=identicon","web_url":"https://gitlab.com/prabhuamtex"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/5","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":9694027,"iid":4,"project_id":5168279,"title":"jjj","description":"![DXkgU83XkAY99NM](/uploads/5c8b13977802a87850c9d474f683200f/DXkgU83XkAY99NM.jpg)","state":"opened","created_at":"2018-03-13T08:51:58.143Z","updated_at":"2018-03-13T08:51:58.143Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":727716,"name":"ganggang","username":"ganggang","state":"active","avatar_url":"https://secure.gravatar.com/avatar/8d2e85d5fd0de2a495fa7bc197918cb6?s=80\u0026d=identicon","web_url":"https://gitlab.com/ganggang"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/4","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":8859575,"iid":3,"project_id":5168279,"title":"cryptocoopx-ccx","description":"","state":"closed","created_at":"2018-01-26T02:32:22.344Z","updated_at":"2018-01-26T02:32:26.864Z","closed_at":"2018-01-26T02:32:26.860Z","closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":1963760,"name":"Naif ALhaider","username":"Naif711","state":"active","avatar_url":"https://secure.gravatar.com/avatar/5e77d108fa5a43b854cd75703a56e98f?s=80\u0026d=identicon","web_url":"https://gitlab.com/Naif711"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/3","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":8859520,"iid":2,"project_id":5168279,"title":"cryptocoopx-ccx","description":"","state":"opened","created_at":"2018-01-26T02:24:43.413Z","updated_at":"2018-02-14T19:38:43.360Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"author":{"id":1963760,"name":"Naif ALhaider","username":"Naif711","state":"active","avatar_url":"https://secure.gravatar.com/avatar/5e77d108fa5a43b854cd75703a56e98f?s=80\u0026d=identicon","web_url":"https://gitlab.com/Naif711"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/2","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null},{"id":8786090,"iid":1,"project_id":5168279,"title":"issur","description":"BUg","state":"opened","created_at":"2018-01-23T07:06:29.246Z","updated_at":"2018-04-13T18:11:38.445Z","closed_at":null,"closed_by":null,"labels":[],"milestone":null,"assignees":[],"auth* Connection #0 to host gitlab.com left intact
or":{"id":1953843,"name":"waqar ahmad","username":"waqar92","state":"active","avatar_url":"https://secure.gravatar.com/avatar/79f866cdc934803a60a2cfded672b430?s=80\u0026d=identicon","web_url":"https://gitlab.com/waqar92"},"assignee":null,"user_notes_count":0,"upvotes":0,"downvotes":0,"due_date":null,"confidential":false,"discussion_locked":null,"web_url":"https://gitlab.com/coldnight/ci-test/issues/1","time_stats":{"time_estimate":0,"total_time_spent":0,"human_time_estimate":null,"human_total_time_spent":null},"weight":null}]%     ```

chris48s · 2018-06-14T21:07:41Z

Thanks for doing some work on this @LVMBDV - appreciate that even answering the question "is there an API endpoint we can use for this badge?" can take some effort sometimes.

I hope GitLab isn't authenticating me through some black magic without a token. Please try the command above to confirm my findings.

I tried the commands you posted and I am getting a response back. Looking at the response headers, it contains keys:

RateLimit-Limit
RateLimit-Observed
RateLimit-Remaining
RateLimit-Reset
RateLimit-ResetTime

so it looks like unauthenticated use is rate-limited. Shields has the potential to generate quite high API traffic if we are proxying use for many users of a popular service, so rate limited access may not be suitable for this. We would probably need to authenticate to stay under rate limits/keep consistent service, even if authentication is not needed for repo permissions.

Additionally if the behaviour you intend to rely on does not match the documentation, maybe post on https://gitlab.com/gitlab-com/support-forum/issues to clarify. I think its better to ensure the behaviour isn't going to change out from under us before submitting a PR for a badge that relies on it.

LVMBDV · 2018-06-14T21:21:13Z

I guess we can do the GitHub token cycling thing with a GitLab application token that doesn't ask for any permissions (just authentication). I tried to create one and I was able to.

Additionally if the behaviour you intend to rely on does not match the documentation, maybe post on https://gitlab.com/gitlab-com/support-forum/issues to clarify.

I should, maybe tomorrow. Will post a link here when I do.

P.S. My authenticated queries came back with the same rate limit (600) so that's another bit of information.

LVMBDV · 2018-06-15T12:02:56Z

I made some progress but I would like to push them and open a PR after I clean it up a bit. I got these working without implementing token cycling yet:

forks
stars
contributors

What I plan to also implement:

last commit's pipeline status
open & closed issues
open & closed merge requests
last activity date
last commit date
total commits
repo size

And of course, token cycling.

paulmelnikow · 2018-06-15T14:25:31Z

Hey, I'm just tuning back into issues here after a little break.

Just a heads up that I rewrote and fixed the Github token cycling logic in #1205. It includes a
service-agnostic TokenPool with tests. It would be interesting to see how well the abstraction carries over to another use case. And it would be great to get some more eyes on that in general. Though sadly, I don't think I'll be comfortable merging it until I get access to server logs.

LVMBDV · 2018-06-15T16:27:19Z

The pooling token provider seems like a better solution to the problem at hand but I want to get GitLab support deployed as soon as possible with the smallest maintenance requirements possible.

I could wait for #1205 to be merged to resume working on GitLab badges built on its token pools or finish it with its own token pool helpers and leave refactoring it after #1205 is merged to someone else.

paulmelnikow · 2018-06-16T16:24:57Z

Yea, I don't see merging #1205 any time soon. At the same time, I don't like adding tech debt / deferred maintenance to get in new features. How about this: I'll open a new PR with the helper classes from #1205, and get that merged, and then you merge in master, and update this to use those classes? That way we're moving the ball forward on both fronts.

LVMBDV · 2018-06-17T14:31:03Z

That would work for me. Thanks.

flxholle · 2020-06-08T14:37:00Z

Until now, I did not find any other badges than build status for GitLab. So I created a repository with examples, that use the basic API information without any access tokens: https://gitlab.com/asdoi/gitlab-badges
As there is now token required maybe some of them can be integrated in shields.io

calebcartwright · 2020-06-09T00:04:00Z

@asdoi - Thank you for sharing. However, there's still outstanding issues around Gitlab's API rate limits (which are IP based AIUI).

The hope was that Gitlab would be able to offer Shields an increased rate limit threshold if the Shields requests were authorized with a known/agreed-to account; it wasn't really about whether the data could be retrieved anonymously (GitHub supports anonymous API calls too, but Shields can't use them due to rate limiting).

IIUC the current thresholds on gitlab.com are 10 requests/second
https://docs.gitlab.com/ee/user/gitlab_com/index.html#gitlabcom-specific-rate-limits

Even during slow/non-peak windows, the Shields servers are issuing well over 1,000 requests/minute to the GitHub APIs, so Shields would almost certainly exceed the Gitlab rate limits given the popularity of the platform.

We won't be able to expand Shields' support for Gitlab badges until this rate limiting issue has been solved.

noraj · 2020-06-09T00:21:10Z

@calebcartwright Is there an issue open on GitLab tracker?

calebcartwright · 2020-06-09T03:47:10Z

I don't know of any @noraj. I know @paulmelnikow had started a dialog with the Gitlab folks but believe the fizzled out.

ENDrain · 2020-10-07T00:32:50Z

But does Shield have to use its own access token? Can user access token be passed to endpoint as a parameter, so that Shield makes an API request with user/group/whatnot token?

PyvesB · 2021-04-18T09:34:16Z

But does Shield have to use its own access token? Can user access token be passed to endpoint as a parameter, so that Shield makes an API request with user/group/whatnot token?

This would be acceptable, as long as it strictly follows the conditions outlined by our contributing guidelines:

Badges may require users to specify a token in the badge URL as long it is scoped only to fetching information and doesn't expose any sensitive information. Generating a token with the correct scope must be clearly documented.

In some cases, the scoping options of an API simply don't allow only fetching information or not exposing sensitive information, I'm unsure whether this is the case with GitLab. However, having an access token would be an overall better solution, as it makes it easier for users and is more consistent with most of our other badges, in particular the GitHub ones.

@paulmelnikow did you ever get round to opening a feature request on GitLab, as was suggested on Twitter?

guillermin · 2021-05-26T10:28:55Z

According to the documentation, the limits that would apply to Shields if it were to have its own access token would be:

2,000 requests per minute for Authenticated API traffic (for a given user)
2,000 requests per minute for All traffic (from a given IP address)

@calebcartwright mentions that for the GitHub APIs Shields is "issuing well over 1,000 requests/minute", but I think 2,000 requests per minute could be a good starting point for GitLab (considering it is less popular than GitHub). If it gets to the point where Shields calls are rejected because of the limit then we could try to ask GitLab for a higher limit, but from my point of view it seems like it would make sense to start with what we have and see if it is enough.

noraj · 2021-05-26T11:30:52Z

There is already an official gitlab badge for pipeline status so it should not be concerned by any rate limit:

[![pipeline status](https://gitlab.com/rawsec/rawsec-cybersecurity-list/badges/master/pipeline.svg)](https://gitlab.com/rawsec/rawsec-cybersecurity-list/commits/master)

This one if already included in shields.io so I guess we should say the CI part is already done

But about generic gitlab badges it's true there is nothing yet in shields.io but it should be feasible since badgen is already doing it (see https://badgen.net/gitlab):

PyvesB · 2021-05-26T12:53:03Z

2,000 requests per minute for Authenticated API traffic (for a given user)

That's significantly higher than the number I gathered from previously reading through this thread. According to the documentation, the limits also seem to have gone up by quite a bit last January, giving even more headroom.

Having a quick look at our dashboards, we peak at ~4000 requests per minute for our GitHub badges, which are by far our most popular offering. Unless I'm missing something, 2000 requests per minute with a single Gitlab token should realistically cover us for the foreseeable future.

Given these new numbers that have come to light, I would personally be happy to green light an implementation that relies on a single Gitlab user token (similar to our Discord, YouTube and several other badges). @badges/shields-maintainers any objections?

calebcartwright · 2021-05-26T13:39:12Z

@noraj

This one if already included in shields.io

Yes, for some time we've had badges in the handful of cases where Gitlab make it possible to get the data without hitting the rate limiting constraints

but it should be feasible since badgen is already doing it

"Service XYZ is doing it" arguments don't really guide the work we do here in Shields.io. Shields runs on a very different scale and we have very different operational concerns than some of the smaller services

@guillermin - thanks for the bump, though two important pieces of context I feel were missing from your note that I want to emphasize

According to the documentation, the limits that would apply to Shields if it were to have its own access token would be

On 2021-01-18 Gitlab apparently changed the limit from 600 requests/minute to 2,000 requests/minute which is indeed a sizeable change that could perhaps unblock us

@calebcartwright mentions that for the GitHub APIs Shields is "issuing well over 1,000 requests/minute",

The previous comment from me that you are quoting was referring to the floor of what we see for GitHub during our absolute slowest traffic hours. As P-Y noted in a subsequent comment, we often see much, much higher traffic which is why we wouldn't want to use that floor as a measuring stick for the total traffic profile of a given set of services like Gitlab. My original point was that our absolute lowest volume for GitHub traffic was nearly double the absolute limit of Gitlab, and that we'd essentially have been guaranteed to hit the Gitlab limits during our more typical traffic load periods.

@PyvesB

Given these new numbers that have come to light, I would personally be happy to green light an implementation that relies on a single Gitlab user token (similar to our Discord, YouTube and several other badges). @badges/shields-maintainers any objections?

I definitely think Gitlab's >3x rate limit increase can potentially unblock us here. I don't have any explicit objections, but am still somewhat cautious (though cautiously optimistic now). I feel like both we as maintainers and our users been bitten hard in the past with rate limit driven issues, and I'd really like to avoid getting into a proverbial case of having to try to rebuild the plane midflight.

I'm open to starting the work to move forward, but my preference would be that we start small (wire up auth and add one or two badges) and observe for a bit before opening the floodgates.

noraj · 2021-05-26T14:14:25Z

@calebcartwright

"Service XYZ is doing it" arguments don't really guide the work we do here in Shields.io. Shields runs on a very different scale and we have very different operational concerns than some of the smaller services

My thought was more "it's an open-source service so we may take a look at what they do, they may have found a way to bypass that limit".

I definitely think Gitlab's >3x rate limit increase can potentially unblock us here. I don't have any explicit objections, but am still somewhat cautious (though cautiously optimistic now). I feel like both we as maintainers and our users been bitten hard in the past with rate limit driven issues, and I'd really like to avoid getting into a proverbial case of having to try to rebuild the plane midflight.

Have you tried to open an issue on gitlab.com bug tracker. They set a limit to avoid abuse but they may be ok to set shields.io in a whitelist to avoid you the rate limit since you're a free libre and open source project. I'm sure they we'll be happy to have gitlab supported in a community project like shields.io.

PyvesB · 2021-05-26T19:00:40Z

Have you tried to open an issue on gitlab.com bug tracker

This question has been asked multiple times already, we're basically going round in circles at this point and creating noise for whoever has subscribed to this issue. Shields.io is a community project, a much more constructive stance would be to help out, open the issue yourself, and report back once you've done so. The Gitlab folks on Twitter have given a few pointers on submitting the feature request. :)

I'm open to starting the work to move forward, but my preference would be that we start small (wire up auth and add one or two badges) and observe for a bit before opening the floodgates.

Makes sense. @guillermin if I reopen #6389, would you be happy to extend it a little by adding the API token support that we have in other services (Discord or Twitch are probably a decent examples)? Depending on the popularity of this unique new badge and on Gitlab's response to the feature request that @noraj is hopefully going to open, we can then make an informed decision on whether to add more Gitlab badges or not. 😉

noraj · 2021-05-26T19:24:05Z

Gitlab issue created: https://gitlab.com/gitlab-org/gitlab/-/issues/331960

noraj · 2021-06-11T16:19:36Z

@espadrine @PyvesB @calebcartwright Hi Shields.io team

Since I opened the issue on Gitlab, Gitlab Open-source collaboration team has started to work on what they can do with teh API rate limiting.

Please answer their questions:

calebcartwright · 2021-07-04T21:32:59Z

@guillermin - just a triage ping to see if you had any thoughts on the above question from P-Y relative to picking your PR back up.

We've decided that the rate limit increase from earlier this year should give us enough breathing room to start incorporating a few badges, while in parallel continuing the discussions with Gitlab.

If someone else wants to pick that up instead, please drop a note here. You can simply fetch the commits by running git fetch origin pull/6389/head:pr-6389. Address the pending review comments and open a new pull request with a co-authored trailer included in the commit message to give attribution to the original author.

guillermin · 2021-07-07T10:00:14Z

Sorry I haven't followed up on this, I was on vacation.

@PyvesB I would gladly extend the PR to add the authentication, but what I don't know is how to handle the creation of the GitLab account: Which credentials (username, email, password) should I use to create the account? The account creation will probably require email validation, who will be able to do that? Where should I store the credentials for future reference?

If you can please help me a bit with the GitLab account creation I can proceed with the necessary modifications.

calebcartwright · 2021-07-07T17:59:07Z

I would gladly extend the PR to add the authentication

Excellent, thank you @guillermin

what I don't know is how to handle the creation of the GitLab account

Don't worry about the actual account. Someone from our ops team will take care of the account creation/selection and wire up our production environment with the details, we just need the service class updated to support making authenticated requests with those configured values. Feel free to ping us with any questions on your PR thread and/or Discord if you have any questions about implementation

chris48s · 2021-07-07T20:09:46Z

In terms of how to add the auth, you may already be on the case but there are existing auth helpers for

HTTPS Basic Auth
Bearer Authorization Header
Auth passed in Query String

in https://github.com/badges/shields/blob/master/core/base-service/auth-helper.js

and the credentials will be set in server secrets: https://github.com/badges/shields/blob/master/doc/server-secrets.md

calebcartwright · 2021-09-14T23:25:52Z

I'm pleased to share that as of #6988 Shields can now support GitLab badges! This issue was centered on the core, foundational pieces needed to make that happen, and so we've accordingly closed it.

Anyone that would like to request a specific GitLab-based badge should follow our standard process by opening a New Badge Request issue with the relevant details.

A few final things to note:

Until further notice all our new GitLab badges should be considered "beta" (this excludes the existing Pipeline Status and Code Coverage badges due to the different way those data points are retrieved). Basically that just means that we could still make changes or potentially even remove certain badges down the road if circumstances require that we pivot. There's still some unresolved discussion upstream with the GitLab folks that could impact our ability to provide these badges at scale, and we have to reserve the right to make adjustments until that comes to a conclusion.
These badges on Shields.io can be used with any internet-accessible GitLab instance, but only for public projects for the time being. We may be able to enhance this down the road, but the presence of the rate limiting/always auth requirement would require some extended support to the auth mechanisms on our end in order to support handling private projects

espadrine added the needs-upstream-help Not actionable without help from a service provider label Nov 10, 2015

bracketttc mentioned this issue Jul 23, 2016

Ruby implementation #753

Closed

ishitatsuyuki mentioned this issue Dec 16, 2016

Add GitLab CI badge support #841

Closed

paulmelnikow added the service-badge New or updated service badge label Apr 18, 2017

paulmelnikow added good first issue New contributors, join in! hacktoberfest and removed needs-upstream-help Not actionable without help from a service provider labels Oct 12, 2017

paulmelnikow removed the hacktoberfest label Nov 1, 2017

paulmelnikow mentioned this issue Jun 16, 2018

Generalized rotating token pool #1736

Merged

chris48s mentioned this issue Apr 4, 2020

Badge Request: GitLab tags and releases #4867

Closed

calebcartwright removed the good first issue New contributors, join in! label Jun 9, 2020

calebcartwright mentioned this issue Dec 30, 2020

Add GitHub badge to GitLab #5997

Closed

PyvesB mentioned this issue Apr 18, 2021

Added [GitLabTag] service #6389

Closed

calebcartwright mentioned this issue Sep 6, 2021

Add API-based support for [GitLab] badges, add new GitLab Tag badge #6988

Merged

repo-ranger bot closed this as completed in #6988 Sep 14, 2021

calebcartwright mentioned this issue Dec 11, 2021

Badge request: GitLab License #7371

Closed

branevukmirovic mentioned this issue Dec 14, 2022

[Snyk] Upgrade chalk from 5.0.1 to 5.1.2 branevukmirovic/shields#44

Open

andruszd mentioned this issue Jun 20, 2023

[Snyk] Security upgrade semver from 6.3.0 to 7.5.2 andruszd/shields#53

Open

kamil1marczak mentioned this issue Jun 21, 2023

[Snyk] Security upgrade semver from 7.3.4 to 7.5.2 kamil1marczak/shields#32

Open

dbalde mentioned this issue Jun 21, 2023

[Snyk] Security upgrade semver from 7.3.2 to 7.5.2 dbalde/shields#126

Open

Badge request: Gitlab CI and Gitlab #541

Badge request: Gitlab CI and Gitlab #541

Comments

tankerkiller125 commented Sep 27, 2015

espadrine commented Oct 5, 2015

tankerkiller125 commented Oct 5, 2015

espadrine commented Oct 5, 2015

tankerkiller125 commented Oct 8, 2015

ishitatsuyuki commented Mar 24, 2016

moeabdol commented Mar 26, 2016

sergeysova commented May 1, 2016

sergeysova commented May 1, 2016

sergeysova commented May 1, 2016

gluons commented Jun 24, 2017

paulmelnikow commented Sep 22, 2017

sum01 commented Jun 12, 2018

LVMBDV commented Jun 14, 2018

Snuggle commented Jun 14, 2018 • edited Loading

chris48s commented Jun 14, 2018

LVMBDV commented Jun 14, 2018

LVMBDV commented Jun 15, 2018 • edited Loading

paulmelnikow commented Jun 15, 2018

LVMBDV commented Jun 15, 2018

paulmelnikow commented Jun 16, 2018

LVMBDV commented Jun 17, 2018

flxholle commented Jun 8, 2020 • edited Loading

calebcartwright commented Jun 9, 2020

noraj commented Jun 9, 2020

calebcartwright commented Jun 9, 2020

ENDrain commented Oct 7, 2020 • edited Loading

PyvesB commented Apr 18, 2021

guillermin commented May 26, 2021

noraj commented May 26, 2021

PyvesB commented May 26, 2021 • edited Loading

calebcartwright commented May 26, 2021

noraj commented May 26, 2021

PyvesB commented May 26, 2021

noraj commented May 26, 2021

noraj commented Jun 11, 2021

calebcartwright commented Jul 4, 2021 • edited Loading

guillermin commented Jul 7, 2021

calebcartwright commented Jul 7, 2021

chris48s commented Jul 7, 2021

calebcartwright commented Sep 14, 2021

Snuggle commented Jun 14, 2018 •

edited

Loading

LVMBDV commented Jun 15, 2018 •

edited

Loading

flxholle commented Jun 8, 2020 •

edited

Loading

ENDrain commented Oct 7, 2020 •

edited

Loading

PyvesB commented May 26, 2021 •

edited

Loading

calebcartwright commented Jul 4, 2021 •

edited

Loading