Apparently we need `ruby-dev` (development headers) package
to build fpm gem's native extensions now?!
Well, it's an easy fix. Not sure why we didn't need this up until now,
but oh, well.
Apparently it's not the "node" cask anymore in the base CI image,
it's the "node@20" cask. Wow.
The workaround of uninstalling this is still needed,
it's just that the package name has changed.
- Pin the base (CI-provided) OS image to Ventura, not Sonoma
- Fixes some C/C++ compilation errors??
- Gives us older XCode & compiler toolchain, I guess?
- Get node using tj/n utility, not Homebrew
- Homebrew "node" package is conflicting with (now deprecated)
"node@16" package, loading dynamic libraries like icu4c
keeps breaking...
- Get Yarn using npm global install, not from Homebrew
- I... honestly don't even know at this point. But Yarn from Homebrew
is breaking somehow, possibly due to it referring back to Homebrew
"node" package, but _that's just a guess_. It's cursed, I guess.
- Get python-setuptools from Homebrew, not from pip
- Why? Why is this necessary? Homebrew, explain? Something about our
"environment being externally managed", so global package installs
with pip aren't allowed. This makes sense to someone. See PEP 668.
- Adjust PATH exports now that there's no "node@16" from Homebrew
I must have accidentally regenerated the token an additional time
after encrypting it last time, such that the encrypted version was
already inactive (regenerated over) by the time the PR went up
to switch to it.
Fingers crossed I've done it correctly this time.
Better to receive future minor/patch updates than pin exact,
considering this dependency used to be totally unbounded ">= 0".
We probably won't remember to update this in the future,
so best to specify a range rather than an exact arbitrary version.
This indirect dependency has a newer version that requires
Ruby 3.0 or newer. We're on Debian 10 "Buster" for now, which is
still on Ruby 2.5.
Pin to dotenv 2.8.1, the latest version compatible with our older Ruby,
per the error message from CI:
> The last version of dotenv (>= 0) to support your Ruby & RubyGems
> was 2.8.1. Try installing it with `gem install dotenv -v 2.8.1`
> and then running the current command again
>
> dotenv requires Ruby version >= 3.0.
> The current ruby version is 2.5.0.
For builds that are effectively skipped, since their tasks are all
skipped or not scheduled in the first place, we shouldn't update
CIRRUS_LAST_GREEN_CHANGE.
Unfortunately, Cirrus *does* update that for builds with no or
all-skipped tasks, for now. They may fix it in the future, we have a
feature request open for it. But for now, this is the workaround.
We were trying to filter for a certain PR label before,
but inadvertently checked the wrong env var,
based on interpreting some guidance we got from Cirrus team.
In researching what it should be instead, it occurred to me we can
indeed use the `CIRRUS_TAG` env var to check for *any tag push*,
which should actually do pretty well at filtering for releases
after all, since releases are the only times we really push tags.
Add a new token that can upload Rolling release binaries from Cirrus
to GitHub Releases for the Rolling repo.
Prefer this token in the upload script if it is set in the
corresponding env var ROLLING_UPLOAD_TOKEN, otherwise try GITHUB_TOKEN
(This allows the script to work in Cirrus, where the new env var will
be set, and in GitHub Actions where we use the GITHUB_TOKEN.)
(Testing to see if this can be set per-script, otherwise we will have
to set it for the whole task instead.)
Without this, the rename_binary_script step has no `node` on the PATH,
and errors out (thus erroring out the entire run
before uploading any binaries)!
Whoops.
Adds a renaming script to rename the binaries with our
Regular release naming scheme, and updates the Cirrus config
to run said renaming script.
De-facto codifies our existing, officially unofficial naming scheme
with a bit of automation.
We can always revise this down the line
if consensus changes for how to name these files.
Just a little institutional knowledge to unburden team members with,
via the (sometimes double-edged sword...) of automation.
