Repository navigation
ci: make the workflow run again (pinning, Docker Hub auth, FreeBSD runner) - #6
Merged
Merged
Conversation
The upstream merge took upstream's trigger block. That dropped the fork's push trigger (earthly-main, gh_test_ci) and limited pull_request to master/main. So CI no longer ran for PRs into earthly-main, including #3 itself. This brings back the push trigger from earthly-main (644b083). It also removes the branch filter from pull_request, so the workflow runs for every PR, whatever its base. A PR into earthly-main would have been enough, but stacked PRs (like this one, based on chore-merge-v0.14.1) need CI too. We keep upstream's workflow_dispatch and schedule triggers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit f2e55f5)
The EarthBuild org requires every action to be pinned to a full commit SHA; with tag pins every job failed at "Set up job" before running. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit e66a226)
bake-action < v5 refuses to run with the buildx now shipped on ubuntu-latest runners. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> (cherry picked from commit e2fbb01)
Anonymous pulls of tonistiigi/xx and mvdan/shfmt hit Docker Hub's 429 rate limit on shared runners. Use the EarthBuild org's CI account (vars.DOCKERHUB_USERNAME / secrets.DOCKERHUB_TOKEN); skipped for fork PRs, which don't receive secrets. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
test-freebsd-amd64 targeted the retired macos-13 runner, so it queued forever and the workflow run never completed. Port upstream tonistiigi/fsutil's approach (vmactions/freebsd-vm on Linux) for the FreeBSD leg, keeping the fork's Go 1.21 and actions pinned by SHA. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Go 1.21 binaries abort with "dyld: missing LC_UUID load command" on the current macos-latest image before any test runs. Go 1.20 keeps macOS coverage; Windows and Linux still run 1.21. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Force the test-os workflow step to use bash so a failing go test command is not masked by a later coverage command on Windows PowerShell. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com> (cherry picked from commit 818582b) Without a shell, windows-latest runs this step in PowerShell, where a failing native command does not stop the script: `go tool cover` succeeding overwrote `go test`'s exit code. Run 37996598366 (jobs 114044153320, 114044153527) logged `--- FAIL: TestHardlinkFilter` yet both Windows jobs concluded success. The other multi-command run steps already stop on failure: the FreeBSD Prepare step sets `shell: bash`, and the FreeBSD Test step runs on ubuntu-latest (default `bash -e`) with `set -ex` inside the VM script. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Windows stat handling does not populate hardlink linknames, so TestHardlinkFilter cannot assert the Unix hardlink normalization behavior there. Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com> (cherry picked from commit a0b4937) Cherry-picked rather than fixed: the failure is pre-existing upstream behaviour, not something the merge or #4 introduced. TestHardlinkFilter arrived with upstream 91a3fc4 (tonistiigi#198), and setUnixOpt in stat_windows.go is a no-op, so the inode map that fills Stat.Linkname for hardlinks never runs on Windows. Upstream's own CI masked the failure the same way until tonistiigi#259, which added `shell: bash` and this skip together (its bash-only run 26987953480 failed all three Windows test-os jobs). With the bash fix alone, workflow_dispatch probes failed the same way on Windows (Go 1.20 and 1.21) on upstream 91a3fc4 (run 38000549628) and on #4's code e66a226 (run 38000552489), with `foo2: The system cannot find the file specified.` and an empty Linkname where "foo" was expected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
janishorsts
approved these changes
Oct 10, 2026
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.
Fixes the fsutil CI workflow so it actually runs, so the stacked merge PRs (#3, #4) get real signal. CI-only, apart from one cherry-picked upstream test skip (
0c1f49d).Stacking: based on
chore-merge-v0.14.1(#3), because #3 replaces the workflow with upstream's. Fixingearthly-main's old workflow would just conflict with #3. Suggested merge order: #3 ← this PR ← #4. #4 carries cherry-picked copies of the first three commits, which become no-ops once this merges.What was broken
push/pull_requesttriggers forearthly-main. Re-enabled, and triggers restored.docker/bake-actionv4 refuses to run with the buildx now onubuntu-latest.tonistiigi/xx,mvdan/shfmt).test-freebsd-amd64targeted the retiredmacos-13runner, so it queued forever and the run never completed.macos-latestaborts withdyld: missing LC_UUID load commandbefore any test runs.test-os's Test step had noshell:, so onwindows-latestit ran in PowerShell, where a failinggo testdoesn't stop the script andgo tool cover's success became the step result. Run 37996598366 logged--- FAIL: TestHardlinkFilteron both Windows jobs, yet both concluded success. The other multi-commandrun:steps already stop on failure: FreeBSD Prepare setsshell: bash, and FreeBSD Test runs onubuntu-latest(defaultbash -e) withset -exinside the VM.TestHardlinkFilterfails on Windows, and it did before the merge. On WindowssetUnixOptis a no-op, so hardlinks never getStat.Linkname. The test arrived with upstream 91a3fc4 (fix hardlink filter regression tonistiigi/fsutil#198), and upstream fixed the CI masking and skipped this test together in ci: run OS tests with bash tonistiigi/fsutil#259. We cherry-pick both commits.Commits
2ceb46aci: run CI for pushes to earthly-main and PRs into any branch (cherry-pick from test+fix: red tests and fixes for upstream merge (stacked on #3) #4)4b6ce42ci: pin actions to full-length commit SHAs (cherry-pick from test+fix: red tests and fixes for upstream merge (stacked on #3) #4)c605ae7ci: bump docker/bake-action to v5 for buildx >= 0.20 (cherry-pick from test+fix: red tests and fixes for upstream merge (stacked on #3) #4)983693eci: log in to Docker Hub with the org CI account (vars.DOCKERHUB_USERNAME/secrets.DOCKERHUB_TOKEN); skipped for fork PRs078c86bci: run FreeBSD in avmactions/freebsd-vmVM onubuntu-latest, as upstream fsutil does13a2fb6ci: exclude Go 1.21 on macOS. Go 1.20 keeps macOS coverage, and Windows/Linux still run 1.21.ef0123fci: run OS tests with bash (cherry-pick of upstream 818582b). Pushing this alone turned both Windows jobs red (run 38000533041: 1.20, 1.21:--- FAIL: TestHardlinkFilter,Process completed with exit code 1), which shows the failure had been hidden.0c1f49dtest: skip hardlink filter on Windows (cherry-pick of upstream a0b4937)Windows
TestHardlinkFilter: already failing upstreamThrowaway
workflow_dispatchprobes ran this PR's workflow withshell: bashandgo test -v. The probe branches have been deleted.TestHardlinkFilteronlyTestHardlinkFilteronlyBoth fail the same way:
expected: "foo"/actual: ""for the linkname, thenCreateFile …\foo2: The system cannot find the file specified.Upstream's bash-only run 26987953480 failed all three of its Windows jobs before the skip went in. Upstream's 2024 runs and their logs have expired, but its workflow at 91a3fc4 had the same PowerShell step.The probe runs were cancelled once their
test-osjobs had finished, so those runs show as cancelled overall.CI now
Run 38001583792 at
0c1f49dis all green. In both Windows logs (1.20, 1.21) the step runs underbash --noprofile --norc -e -o pipefail, there are 0FAILlines, and the result isok github.com/tonistiigi/fsutil.🤖 Generated with Claude Code