CI: Delete hardcoded GITHUB_TOKEN reference (Cirrus)

[DeeDeeG]

Change

Delete hardcoded GITHUB_TOKEN in Cirrus CI config file (.cirrus.yml)

Commentary (Rationale)

We can define this (encrypted) token on the web dashboard, instead of hard-coding (an encrypted reference to) it in a repo file, to save ourselves the trouble of updating it in the file every time it expires.

This token isn't particularly sensitive, as it has no permissions. It's only for authing as a real user so rate limits are relaxed, letting us download vscode-ripgrep from an otherwise heavily rate-limited datacenter / "cloud" machine that we call "CI."

For the more sensitive tokens, I'd like to be able to apply them per-step. Which I don't think the Cirrus web dashboard lets you do. This one should be alright to define globally.
(Heck, we already do define this one for the whole CI build file! Moving it to the web dashboard won't change that.)

Verification Process

I can trigger a Cron job on this branch, I guess.

Yep, it worked: https://cirrus-ci.com/task/4603233122910208

(ARM Linux needs some help with a newer Python version due to #1223. But it got past installing its npm deps, so this PR's fix worked there, too!)

UPDATE: ARM Linux Cirrus was fixed by #1237.

[DeeDeeG]

Okay, as it turns out, the web override does work, regardless of what the env var is defined as in the file.

So, this PR does not technically change anything, it's already being handled on the web dashboard, however it does serve as documentation, a reminder/hint to us as maintainers to do this on the web dashboard for Cirrus, not in the .cirrus.yml file, going forward.

We need to go to the dashboard to generate a new encrypted token either way, so not having to do a PR on top of that is very much preferable, IMO. So, this new paradigm (and documenting it with this PR) is my strong preference going forward.

But that just means merging this is optional. Again, this serves a just a docs improvement PR, basically, now that I have confirmed more details of how this works on the Cirrus side.

[DeeDeeG]

By the way (regarding this PR's own CI pass/fail status readout): I manually canceled the Apple Silicon Cirrus run to avoid spamming pulsar-rolling-releases with more bins. Apple Silicon Cirrus is passing now if I don't cancel it, since the web dashboard token override is working. 👍

And ARM Linux Cirrus runs are genuinely failing for reasons separate from this PR. The ARM Linux Cirrus runs need some sort of intervention to have a compatible Python version after the latest ppm bump #1223.

[meadowsys]

I think we can just remove this old value entirely, but I do agree with keeping a comment here documenting the use of a permissionless token here.

[DeeDeeG]

I am drafting a commit to address this review feedback. Is one of the following preferable? Or something else?

  PYTHON_VERSION: 3.12
  # GITHUB_TOKEN: 
  # The above token, is a GitHub API Token, that allows us to download RipGrep without concern of API limits.
  # We define it on the Cirrus web dashboard now, though. That way we don't need to update repo files (this file),
  # or open any PR's and wait for review, just to update a permissionless token. (Expired tokens can block CI from passing/finishing!)

^ Just the old value removed.

  PYTHON_VERSION: 3.12
  # Note: the GITHUB_TOKEN env var holds a GitHub API Token, that allows us to download RipGrep without concern of API limits.
  # We define it on the Cirrus web dashboard now, though. That way we don't need to update repo files (this file),
  # or open any PR's and wait for review, just to update a permissionless token. (Expired tokens can block CI from passing/finishing!)

^ Deleting the line that had defined the env var in .cirrus.yml, and adjusting the text afterward to make sense.

Thanks for taking a look. 👍

[meadowsys]

presuming it's possible, I feel like we could remove all hardcoded secret references in this file and define them using the web dashboard

edit: I actually read through your comments now, lol. Not great that we can't apply the secrets per step if they're defined in the web dashboard, I'd definitely prefer the extra security over this convenience