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.
Effectively: install ppm's dependencies (and run its postinstall
scripts) with Yarn, not npm, on Windows.
This makes the installation of ppm's dependencies consistently use
Yarn, not npm, in Cirrus CI. Consistent for all OSes/arches we build
for in Cirrus.
(* Although, at some level the postinstall scripts are run via npm as
a subprocess of node as a subprocess of Yarn in a shell/console
sub-process... Yes, in my opinion, ppm's postinstall scripts are way
too complicated...)
ALSO: This fixes an oversight in PR 239 where the build script of the
wrong project (ppm instead of core) was being run at one point, again
on Windows.
So, this should make it so Pulsar's core dependencies are built for
the correct Electron version instead of built for Node... Oops!