CI: Use Python 3.11 to fix macOS signing #743
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background and context for this Pull Request...
It's a long story, click to expand if you want:
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 been 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.
Credit where due
By the way, co-credit for this goes to @confused-Techie for the idea to try and replicate our steps for setting up for the build in the Cirrus CI environment, re-creating them here in GitHub Actions. This was the big inspiration for trying to test every possible difference in the things we control that might be different in how the Cirrus and GitHub Actions were set up, and led directly toward the final stretch "process of elimination" testing efforts that culminated in this PR. (See #742 for the first half of these efforts). And for discussing back and forth throughout all this. Felt a lot less daunting tackling this with two+ people working on it.
Also thanks to @meadowsys for helping with the debugging and answering some questions about the signing process, which helped to narrow down where the problem wasn't, so we could focus with more confidence on what else it could be.
Identify the Bug
Well, macOS binaries from GitHub Actions have been signed (as can be verified with
spctl
orstapler
, and so on) but still warning that they can't be verified, just like any not signed binary usually would.This is since we started building any binaries on GitHub Actions. (#682)
(This is another shot at what #742 was getting at. Hopefully we've got it solved now (see "Verification Process" below).)
Description of the Change
Start using Python 3.11 in GitHub Actions.
Before anyone asks: No, I don't know why this fixes the problem, I don't know why there was a problem in the first place.
Alternate Designs
We could just delete the
actions/setup-python
step, but then we'd eventually auto-update to Python 3.12 at some point, which I'd like to avoid the surprise of that.There may be other ways of getting Python (some as elaborate as installing an entire new package manager like Homebrew), but I don't see the point in any alternatives, so long as this works.
(If Python 3.11 from actions/setup-python stops working, then sure we can try either of these alternative options.)
Possible Drawbacks
Should be none, since we should have new enough node-gyp now to handle Python 3.11. Being stuck on old node-gyp was the reason we pinned to Python 3.10 in the first place, not an issue now.
(Fixed in pulsar-edit/ppm#79 and pulsar-edit/ppm#94 in ppm repo, --> #725 at this core editor repo.)
To be clear, this may require the CI environment to have relatively recent npm, which it apparently does, since it worked in a test run of this change in CI already before I opened this PR (see "Verification Process" just below).
Verification Process
NOT YET VERIFIED: CI assets for this PR should open without a Gatekeeper warning saying it couldn't be verified (only the usual "this was downloaded from the internet" warning that always shows, even for signed packages, when downloaded from the internet.) (UPDATE: Verified, it works. ✅ )Release Notes
Fixed signing for intel macOS binaries in GitHub Actions