Shields: Badge request: Cirrus CI

[AlexWayfer]

Hello!

Please, add Cirrus CI badge(s).

https://cirrus-ci.org/

Badges from this service itself: https://cirrus-ci.org/guide/writing-tasks/#embedded-badges

/cc @fkorotkov

Thanks!

[PyvesB]

Hello @AlexWayfer!

Thank you for your suggestion. Do you know if Cirrus CI has a proper json/xml/... API or has plans to implement one? We could use the badges of the service itself to construct our own, but this approach is more brittle (see #1329 and #1985 for examples of Shields's badges breaking because of changes in the service's own badges). 😉

Cheers,

Pyves

[AlexWayfer]

Do you know if Cirrus CI has a proper json/xml/... API or has plans to implement one?

I don't know, so I've mentioned @fkorotkov from Cirrus CI: I think he can help.

[PyvesB]

Awesome, let's wait for his thoughts then!

[fkorotkov]

Sorry I'm a bit out of context. Cirrus CI already provides a way to get shields-like badges on it's own. See documentation.

shileds.io gets a status from different APIs and shows badges? Basically just proxies? Do I understand it correctly? How then shileds.io handles authentication to show badges for private repositories? Our endpoint verifies that a request comes from a user with read permissions to a repository.

Do we need to implement some kind of special API?

[paulmelnikow]

Hi @fkorotkov!

Yes, most of the time we make an API request and then format the data into the badge. Compared to vendor native badges, the badges we host are more consistently customizable in terms of label, color, and shape, though for many users it makes no difference.

For security reasons, we don't accept secret read–write tokens on the public servers. Users who wish to host their own copy of Shields could configure their own server with a global token. We have this in place for many other services.

The best way to do this on the public server is for you to let users generate a status-only API key. That's a token which provides access solely to read build status, and thus would be safe to include in a public web page. If you give _us_ a way to reject other tokens, like giving all the status-only keys a status_ prefix – we can help keep your users secure.

UptimeRobot has this, for example: it's called a monitor-specific API key. They all start with m which means we outright reject the user tokens which give access to more.

In terms of a JSON status endpoint, we could suggest something if it would be helpful. Most services offer latest build on default branch + latest build on a specific branch. If you have workflows, or details on tests passed / failed, you could include that as well.

[fkorotkov]

Ok, cool! Seems we'll need to do something on our side for these status-only API key. Will put on our roadmap. 🙌

[AlexWayfer]

Will put on our roadmap. raised_hands

I think, it's private. Do you have any predictions for this task?

[fkorotkov]

We did implement a proper API access but not yet a way to have scoped access tokens for such a use case. Created https://github.com/cirruslabs/cirrus-ci-docs/issues/200 to publicly track it.

[AlexWayfer]

We did implement a proper API access but not yet a way to have scoped access tokens for such a use case. Created cirruslabs/cirrus-ci-docs#200 to publicly track it.

Thank you!