CircleCI : use only Status permission for the API calls

[Horgix]

tl;dr : I think the CircleCI badge with token should be able to work with an API token having the "Status" scope only

When generating an API token for CircleCI (used for private projects badges), it is possible to assign a scope to it. They currently support 3 scopes : "Status", "Build artifacts" and "all".

"Status" scope should be enough to get informations for a badge, and it is the scope used for the "official" CircleCI tokens. Yet, shields.io requires a "all" scope, and will display a "permission denied" badge otherwise. I think that it could and should be limited to API calls allowed by the "Status" permission since it's made for it; and I am a bit concerned about using "all" scope for a badge since it gives full access to the API on a private project...

[Horgix]

Any opinion on that?

If you tell me that a PR fixing this would get merged I might implement it 🙂

[paulmelnikow]

Hi! This sounds like an excellent idea. If you can work up a pull request and add some tests I would be really happy to review and merge it.

[Horgix]

It looks like there is no endpoint on CircleCI that is able to make use of this restricted scope for now 🙁
I opened a Feature Request to CircleCI here : "CircleCI / Get branch status with status-only scoped API token "

I'll follow up here when I get some news!

[RedSparr0w]

There was a little bit of talk about this awhile ago here, not sure if anything has changed on CircleCI's end since then though.

A build-artifacts token should be enough for the badge

Token Scope	Image	Api Link	Api Message
Status		link	"Permission denied"
View-Builds / Build Artifacts		link
All		link
Missing Token		link	"Project not found"

[Horgix]

Thanks for the input @RedSparr0w , much appreciated 👍
I can confirm that it works with the "Build Artifacts" scope; however I still think that it would be best to be able to use only a "Status" scoped token, do you agree?

I think I'll let this open until I get some news from CircleCI about the request of a new endpoint being able to work with a status-only scoped token

[paulmelnikow]

Huh. How come doesn't the status token doesn't work for our badge?

[RedSparr0w]

The status token doesn't seem to do anything from what i can tell, always get a permission denied message from the API with the status token.

{
  "message" : "Permission denied"
}

Haven't found any endpoint which accepts it.
I hope its just an oversight on CircleCI's end but not sure.
The only other way i could think to solve this issue is to parse the shields badge that CircleCI provides.

Edit: maybe that's the only thing the status token supports

[paulmelnikow]

So, it sounds like we could use a build-artifacts token and use the API, or else use a status token with the status badge.

I wonder, would using the status badge help us solve #1995? (cc @chris48s)

This just came up because @haythem just added some documentation in #2379, and I'm wondering if we should tweak it.

It's also worth noting that the Circle badge is the one exception to our typical pattern of not accepting secret tokens. It might be worth noting that somewhere, perhaps in a code comment.

[chris48s]

I've not tried, but if there's a SVG badge we can probably scrape it using the BaseSvgScrapingService class. If that gives us a status value which aggregates all the builds in a workflow, that would indeed make all the faffing about I've proposed in #1995 pointless (which would be a good thing).

[paulmelnikow]

The Circle route will need to be updated for #3329.

While Shields has long had a policy of not accepting secrets on the public badge service, this service has been an exception. Perhaps we could resolve the policy conflict by solving this issue. If the badge is using a status-only token, we're in fine shape.

It should fix #1872 and #1495 at the same time.