Repository navigation
Build x86_64_linux releases on the self-hosted runners - #19
Merged
Merged
Conversation
build.yml gains a self_hosted input. When set, x86_64_linux jobs run on [self-hosted, linux, x64], the same labels hatchbox.io's CI uses; arm64_linux always stays on GitHub's hosted arm runner because the self-hosted runners are x64 only. release.yml turns it on by default, with a workflow_dispatch input to fall back to GitHub's runners when needed. tests.yml leaves it off so pull requests, which anyone can open on this public repository, keep running on GitHub's runners. The manylinux container runs as root, so the files it writes into the workspace are root-owned. On a hosted runner that never mattered, but a self-hosted workspace outlives the job and the next checkout's clean would fail on those files. The in-container chown that only ran after a successful build becomes an always() step that hands the whole workspace back to the runner user.
… host Ruby ruby/setup-ruby on a self-hosted runner installs into the shared /opt/hostedtoolcache, and two jobs extracting the same Ruby there at once race each other: a test run on the org runners failed with tar unable to open libruby.so while the other runner was writing it. The only thing the build jobs used Ruby for was reading the target's container out of recipes/targets.yml, which the plan job can do once and carry in the matrix. The job gets an explicit name so the container reference does not end up in it.
This file contains hidden or 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
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.
Summary
build.ymlgains aself_hostedinput. When true,x86_64_linuxjobs run on[self-hosted, linux, x64], the same labels hatchbox.io's CI uses.arm64_linuxalways stays onubuntu-22.04-armsince the self-hosted runners are x64 only.release.ymlturns it on by default, with a dispatch input to fall back to GitHub's runners when needed.gh workflow run release.ymlfromrelease-new.ymlpicks up the default.tests.ymlleaves it off: pull requests on this public repository can come from anyone.chownthat only ran after a successful build becomes anif: always()step. On a self-hosted runner the workspace outlives the job, and root-owned leftovers from a failed build would otherwise break the next checkout's clean.ruby/setup-ruby. On self-hosted runners it installs into the shared/opt/hostedtoolcache, and the first test run had two jobs race extracting the same Ruby there. The only thing the jobs used Ruby for was reading the target's container out ofrecipes/targets.yml, which theplanjob now does once and carries in the matrix. The job gets an explicit name so the container reference stays out of it.Verified
The runners are registered at the org level with public repositories allowed. A manual Build of 3.4.9 with
self_hosted: true(run) put both x86_64 jobs on the self-hosted runners and both arm64 jobs on GitHub. All four passed in about 8 minutes each, including the ownership step.Each x86_64 build pulls the manylinux image and leaves
.build/.cachetrees in the runner workspace until the next checkout cleans them, so disk on the runner host is worth watching during the first full rebuild.