There is an issue with the libiconv library not being available
in macOS 14 out of the box. We can get it from Homebrew perhaps,
but for now pin to macos-12 runner images so we can be assured
of having working CI faster, without having to R&D a libiconv-
related workaround for macOS 14.
Most of these were old versions of actions
which were running on Node 16. Upgraded them to newer versions
which run on Node 20 instead.
Also tried to replace setup-xvfb action with a direct xvfb-run command.
Let's hope this works.
The Rolling binary upload script gets the version from
package.json in the repository files, not from the binary
itself. So, we need to set this value in the repository's
package.json file, regardless of what version the binary itself has.
The version string in package.json is used by the Rolling upload script
to decide what the tag name will be when creating a new Rolling release.
We want timestamped version strings so they are unique,
and older releases are not overwritten/clobbered/won't have conflicts
(whichever would have happened, not worth finding out).
Besides that this restores the convention we had been uploading
the Rolling release tags with so far.
Set a version timestamp just before building the binaries, like on
the other two platforms. Add this to the outputs of the "build" job
if on Linux. Then read this output in the "test and upload, Linux" job.
Now we have synced timestamps again (as much as we did before building
Linux binaries in a Debian 10 Docker container, anyway).
The script could be updated to check the binary itself,
but this way is easier.
For compatibility with older Linux distros
Debian 8 is pretty much end-of-life now.
Debian 10 should be old enough to have compatible glibc for RHEL 8.
Older versions of node-gyp are incompatible with Python 3.12+,
at least out of the box, since Python 3.12+ no-longer ship with
'distutils' out of the box.
We can work around it by installing 'setuptools' package,
which comes with the required 'distutils'.
Newer versions of node-gyp should come with a fix for this,
but older Yarn or npm will ship with older node-gyp, so here we are.
Note that this isn't really needed on the ubuntu-based CI workflows
for now, since those are on the rather conservatively-updated
Debian/Ubuntu-packaged versions of Python (no newer than Python 3.11,
at present.) But being proactive means this won't sneak up on us later.
GitHub Actions was set to only build for branch pushes (only master
branch due to the branch filter), PRs, and manual workflow dispatches.
Now, GitHub Actions will also build for tag pushes.
This helps to ensure Regular releases
get signed binaries built for them.
(GitHub Actions is set to only *sign* the binaries for push events.
Tag creations/pushes will generate push events, so tag pushes should
indeed make signed binaries, not unsigned ones.)
Before, we were unintentionally not signing for pushes, and only
signing for PRs.
We definitely *do* want to sign for pushes,
(such as to `master` branch), so that Rolling releases get signed,
but we probably don't need (and probably don't want?) to sign for PRs.
(Regardless of whether from a fork or not.)
So, this commit essentially reverses the situation from before:
- DO sign for branch pushes. (Note: the workflow currently only
triggers for `master` branch pushes.)
- DON'T sign for any other events, such as for Pull Requests.
(This change is for GitHub Actions only, as the Cirrus config was
already set up in a very particular way during the migration of most
binary builds to GitHub Actions, which was quite recent,
and doesn't need any changes at this time.)
Background and context for this commit...
Not sure why exactly, but our GitHub Actions workflow is producing
*signed* macOS binaries that pass spctl "acceptance" on the CLI, and
various other signing/notarization checks on the CLI, such as stapler,
but nevertheless warn they can't be verified when opening the signed
Pulsar.app in Finder or using `open` on the CLI, and so on.
Through investigating what changes we can make to better-match the
Cirrus environment, which has producing signed binaries that open just
fine without the warning for months now, we have tried many things.
Eventually, disabling actions/setup-node and actions/setup-python was
tried, which incidentally got us Python 3.11 instead of our manually
pinned older Python 3.10. That worked, the signed binaries open as
they should, sans verification warning.
Further narrowing it down resulted in, any way we get Python other
than 3.10 from actions/setup-python seems to be working.
Given that, this commit starts using Python 3.11 in GitHub Actions,
to fix the "macOS is signed but is still not making Gatekeeper happy"
situation we have been having with GitHub Actions.
This script renames the Pulsar binaries to use the naming scheme
we use for all of the Regular release binaries.
It was already added to the Cirrus config,
now it's used in the GitHub Actions workflow as well.
(It checks the version string in package.json to know not to rename
the binaries unless we're actually trying to make a Regular release.)
