HTTP 403 error during GitHub action

[JakeQZ]

This has happened twice now on the weekly CI build:

• https://github.com/MyIntervals/emogrifier/actions/runs/3672344362/jobs/6208433701
• https://github.com/MyIntervals/emogrifier/actions/runs/3778793431/jobs/6423554059

In the first instance, re-running the job resulted in successful completion. I have not bothered to re-run the 2nd failed job. But it successfully completed a week ago (note these two failures are two weeks apart, and the job is run weekly) and there have been no commits since.

I have an open ticket with GitHub regarding this, which I will be unable to cross-link.

[JakeQZ]

I have an open ticket with GitHub regarding this, which I will cross-link.

That was actually closed. I've reopened it. But cross-linking with GitHub tickets doesn't seem to work anyway.

[JakeQZ]

I posted an update here but it has vanished or been deleted. So here it is again, roughly. The below is a quote.

---

From the two run examples you shared in the linked issue, I'm seeing that these requests didn't get far and 403'd pretty much immediately. I'm not seeing any additional info in our internal tooling beyond the request ending at a 403 status - and that the request looks to be unauthenticated (which is okay since the targets are public, but it may lead to some rate limiting for unauthenticated requests).

I noticed that the workflow is using phive to install. To be on the consistent-side with avoiding any rate-limiting or authentication issues when the install command calls GitHub APIs, I see that the maintainers of phive stated you can pass an authentication token through an environment variable GITHUB_AUTH_TOKEN.

References:
phar-io/phive#384
phar-io/phive#127

Adjusting these pieces of your workflow to add the GITHUB_TOKEN value to a GITHUB_AUTH_TOKEN var in the step's env key should help avoid any further 403's - and if more do appear, please share and we can re-investigate:

- name: Install development tools
   env:
      GITHUB_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
   run: phive --no-progress install --trust-gpg-keys ...

[JakeQZ]

Another failure today. I would attach the evidence, but

[oliverklee]

These errors happens either due to network problems or due to downtime of one of the affected servers/services. As long as they happen only every now and then, I propose we restart the corresponding check and otherwise ignore those failures.

[JakeQZ]

These errors happens either due to network problems or due to downtime of one of the affected servers/services.

According to the above, the problems occur due to deliberate rate-limiting by GitHub, not a network failure or downtime. See the referenced Phive issues.

As long as they happen only every now and then

The problem seems to occur on something approaching 50% of all CI build runs. It's not a one-off. (I think I am getting all the notifications because recently I've usually committed the latest change, through reviewing and approving changes, though I've not actually made the change myself.)

[oliverklee]

Ah, thanks, I see. Then we probably need to configure something.

[JakeQZ]

we probably need to configure something.

The suggestion above using GITHUB_AUTH_TOKEN in the YAML may do the trick.

[JakeQZ]

The suggestion above using GITHUB_AUTH_TOKEN in the YAML may do the trick.

Though some comments in the linked Phive issues suggest doing so may introduce a security vulnerability. I have not fully understood the implications.

[JakeQZ]

Not even the correct HTTP response.

It should be something like 429 Too Many Requests.

Though expecing Microsoft to get it right is probably too much to ask for.

[JakeQZ]

I cannot work with this rubbish platform. I would like to attach a .eml file to illustrate the problem, but I am not allowed to to so, perhaps on the stupid basis of legacy DOS file extensions. These files are text-only email transcripts and not by default opened by a code interpreter. I mean: really?!?