Support GitHub workflow badge for private repos

[agboom]

📋 Description

The GitHub workflow badge does not support private repos, even with a PAT with access to them.

If I understand the code correctly, the current GithubActionsWorkflowStatus badge service uses the public url for Workflow Status badges to fetch the workflow status and converts it to a Shields badge. That would explain why the status of private repos results in a repo or workflow not found.
As said in the GitHub docs:

Workflow badges in a private repository are not accessible externally, so you won't be able to embed them or link to them from an external site.

To support this I think the GitHub API needs to be used instead.

[chris48s]

The history behind why this badge doesn't use the API is long and spread across many issues, but we did at one point migrate this to use the API instead of scraping GitHub's native badge.

Unfortunately, this introduced several bugs that we weren't able to solve using the data/endpoints exposed by the API so we switched back to scraping the native badge. The key issue is #8733 (this was one of the bugs introduced by switching to the API as the data source) and to solve it we picked option 3 from #8733 (comment) . We accepted that the tradeoff of that solution is that users who self host would not be able to use it for private repos, but it is a known limitation rather than an unexpected bug.

If you want to read the whole saga that lead to this, the relevant issues and PRs are:

• Switch GitHub Workflow Status Badge to API #4587
• Not valid Github status badge for broken workflow #8146
• switch from github workflows to github actions workflows; test [githubactionsworkflowstatus githubworkflowstatus] #8475
• Change to GitHub workflow badge routes #8671
• Github Actions Workflow badge not working for "branchless" push #8736
• Github workflow badge showing failure when is not the case #8733
• switch [GithubActionsWorkflowStatus] to SVG scraper #8738

I haven't really looked at #9190 but I suspect you're probably introducing the same bugs I introduced in #8475 when I tried to migrate this before and then reverted in #8738.

[agboom]

Thanks for your write-up! I should have searched more thoroughly before I created this issue, sorry about that.

Based on the information I see a few roads forward:

• We keep the implementation as-is and close the PR. It might be useful to document the private repo limitation somewhere on the Shields site if it's possible?
• We implement the API based version as a separate badge service with a different url. Maybe mark it as experimental to indicate there may be bugs (show this experimental status on the Shields site if possible?).
• We try to reproduce the bugs using tests and fix them in the new implementation (although if the bugs are upstream on the API side, this is not possible of course).

Let me know what you think. I'm entirely fine with closing the PR and this issue, but I'm also willing to try some more to make it work.

[agboom]

Looking at the issues more closely I understand that using the API has some problems outside of our control that affect the performance required for this badge. In that case I think we indeed have no choice but to use the SVG scraper.

[chris48s]

I should have searched more thoroughly before I created this issue

No worries. As I said, the history of this is spread across multiple discussions so there isn't really a single search result that would have given all the background on this.

Looking at the issues more closely I understand that using the API has some problems outside of our control that affect the performance required for this badge

Yeah pretty much. It is not that it is impossible to implement the correct behaviour using the data exposed by the API, but we found it was not really possible to do it inside the timeframe we need to render a badge.

[agboom]

I'll close this issue and the PR, thanks for following up on it 🙏.