fetch-configlet: make authenticated requests

[ee7]

(Edited after discussion below):

The configlet CI check in a track repo would sometimes fail due to a rate limiting error. That happened because the check runs this repo's fetch-configlet script, which was making unauthenticated requests (for which the rate limit is low).

Make curl perform authenticated requests, which have a higher rate limit of 1000 requests per hour per repository. The GITHUB_TOKEN environment variable is not set when the script is run, because we're in a composite action. So this commit sets GH_TOKEN, as advised by an error that occurs when using gh in the same context without setting a token:

    gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:
      env:
        GH_TOKEN: ${{ github.token }}

Note that the fetch-configlet script present in every track repo (and synced via exercism/org-wide-files) is designed for local use, but already uses GITHUB_TOKEN when available. For robust CI, we want to keep using a separate version in a non-track repo for now.

Closes: #101

---

I think this works. I've tested with:

• ee7/exercism-nim@31f084e
• https://github.com/ee7/exercism-nim/actions/runs/3883336081/jobs/6624523492#step:3:17

But if we're happy to merge, we should immediately trigger a configlet job manually on a track, and revert the change in this repo if it fails.

[SaschaMann]

Docs tell me this should be GITHUB_TOKEN: https://docs.github.com/en/actions/using-workflows/using-github-cli-in-workflows but I was also under the impression that GITHUB_TOKEN is already set by default and is only needed if one wants to use a non-default token, so we might not need to set it at all.

Since you tested it, I assume it works, just pointing this out so we can be sure. Feel free to ignore my comment if you've already checked it.

We could test if it works as intended by temporarily adding a call to the rate limit endpoint for debugging:

gh api \
  -H "Accept: application/vnd.github+json" \
  /rate_limit

which should return something just under 1000 requests remaining if the authentication worked properly.

[ee7]

Docs tell me this should be GITHUB_TOKEN: https://docs.github.com/en/actions/using-workflows/using-github-cli-in-workflows but I was also under the impression that GITHUB_TOKEN is already set by default and is only needed if one wants to use a non-default token, so we might not need to set it at all.

That's what I thought too. But when I tested the second commit in this PR, CI failed with:

gh: To use GitHub CLI in a GitHub Actions workflow, set the GH_TOKEN environment variable. Example:
  env:
    GH_TOKEN: ${{ github.token }}

The change to advise using github.token rather than secrets.GITHUB_TOKEN is recent.

That commit closed cli/cli#6534, which mentions:

There is absolutely a secrets.GITHUB_TOKEN https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow

Though, I would guess, it's only available to top-level workflows and not deep within composite actions. If github.token is more versatile, I agree with your proposed change to swap the former with the latter, because when they both exist, they should have identical values.

So it's tricky. It looks like GITHUB_TOKEN isn't set at the time we call the script.

We could test if it works as intended by temporarily adding a call to the rate limit endpoint for debugging

Nice idea. I'll try it later. But I'm led to believe that gh release download never makes an unauthenticated request, and fails immediately otherwise.

[SaschaMann]

That's what I thought too. But when I tested the second commit in this PR, CI failed with:

Love their consistency 🥴

Anyway, in that case consider my comment moot

[ErikSchierboom]

I noticed the github.token reference too.

Nice idea. I'll try it later. But I'm led to believe that gh release download never makes an unauthenticated request, and fails immediately otherwise.

Interesting. One way in which we could check that would be to check the rate limit before and after downloading the release. This can be done via gh api /rate_limit. @ee7 Could you try that?

[ee7]

Could you try that?

Done: https://github.com/ee7/exercism-nim/actions/runs/3883336081/jobs/6624523492#step:3:17

Immediately before running the script:

{
  "resources": {
    "core": {
      "limit": 1000,
      "used": 0,
      "remaining": 1000,
      "reset": 1673357434
    },
  ...
}

Immediately after:

{
  "resources": {
    "core": {
      "limit": 1000,
      "used": 1,
      "remaining": 999,
      "reset": 1673357434
    },
  ...
}

[ErikSchierboom]

Perfect!

[ee7]

I decided to split this PR.

Follow-ups:

• fetch-configlet: use gh, not curl #109
• fetch-configlet: use new asset naming scheme #110

The end state after the follow-ups is the same as what was successfully tested in the past.

I've tested this PR again, so this should be good to merge with the cavaet from the top post:

if we're happy to merge, we should immediately trigger a configlet job manually on a track, and revert the change in this repo if it fails.

[ErikSchierboom]

It works: https://github.com/exercism/csharp/actions/runs/3883508848/jobs/6624899913 🎉 Thanks a lot!