chore: Fix CI after GHA's drop of node16 actions #1574
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
mjameswh
changed the title
Sushisource
approved these changes
Nov 27, 2024
josh-berry
reviewed
Nov 27, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
What changed
Modified our GHA workflows so that when building the release-grade native artifacts on Linux targets, only the actual Rust compilation step runs inside a GLIBC 2.24-based Docker container; all other operations are performed directly on the runner, which can now be any recent Ubuntu.
This was required because GHA no longer allows actions based on Node16 (i.e. actions are forced to use Node20 instead), but Node20 requires at least GLIBC 2.28. It is therefore not possible to have a single execution environment that can both execute Node20-based actions, yet produces native libraries that can then execute in the GLIBC 2.24-based environments that some of our users have.
Given that the build-step-in-docker approach is much slower and less likely to benefit from the build cache, we only use that approach when building release-grade native artifacts. That is, we use a fast, non-docker and non-glibc-24-compatible build approach in 'Continuous Integration', but a longer, optimized and glibc-24 compatible build in 'Build Packages'.