ci: bump actions/cache to v4 and actions/setup-go to v5 - #66
Merged
Conversation
GitHub has shut down the cache service backend for actions/cache v1/v2, so any run declaring actions/cache@v2 is now automatically failed. The path/key/restore-keys inputs are unchanged from v2 to v4, so no config migration is needed beyond the version bump. Use v4 rather than v3 since v3's node16 runtime is also deprecated. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Wei-Chun, Chang <wcchang@infuseai.io>
macos-latest is now macos-26-arm64, so setup-go must fetch a darwin-arm64 Go build. The actions/go-versions manifest only carries darwin-arm64 from 1.19.10 onward, so Go 1.17 and 1.18 miss the manifest and fall through to setup-go's direct download path. In v2 that path is hardcoded to storage.googleapis.com/golang, which now returns 403 for every file. v5 downloads from go.dev/dl instead, where the 1.17.13 and 1.18.10 darwin-arm64 tarballs are available. setup-go v4+ enables its own module cache by default. In unit-test it runs before checkout, so it finds no go.sum, logs a warning and caches nothing. The existing actions/cache step is unaffected. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Wei-Chun, Chang <wcchang@infuseai.io>
wcchang1115
marked this pull request as ready for review
August 8, 2026 07:39
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.
Background
Two separate breakages stop the
Go testworkflow from running.1.
actions/cache@v2is dead. GitHub shut down the cache service backend for v1/v2. Any run that declaresactions/cache@v2is now failed outright, not just warned — e.g. run 29621107772.2.
actions/setup-go@v2cannot install Go 1.17/1.18 on macOS.macos-latestis nowmacos-26-arm64, so setup-go needs adarwin-arm64build. Theactions/go-versionsmanifest only carriesdarwin-arm64from 1.19.10 onward, so 1.17 and 1.18 miss the manifest and fall through to setup-go's direct download path. In v2 that path is hardcoded tostorage.googleapis.com/golang, which now returns 403 for every file.Only the macOS 1.17 and 1.18 jobs hit this — ubuntu finds
linux-x64in the manifest, and macOS 1.19/1.20 finddarwin-arm64.Fix
actions/cache@v2→@v4actions/setup-go@v2→@v5go.dev/dlinstead of the dead bucketNotes
v4, notv3path/key/restore-keys, unchanged from v2 to v4cache: falsego.sumfor the key. Inunit-testit runs before checkout, so it logsRestore cache failed: Dependencies file is not foundand caches nothing. The error is caught insrc/main.ts, so the job is unaffected — the existingactions/cachestep still does the caching. Left off to keep the diff to two lines.actions/checkout@v2left aloneVerified download URLs:
storage.googleapis.com/golang/go1.17.13.darwin-arm64.tar.gzgo.dev/dl/go1.17.13.darwin-arm64.tar.gzgo.dev/dl/go1.18.10.darwin-arm64.tar.gzOut of scope
it-test-s3fails separately withInvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records.The repo's AWS secrets are invalid or expired. Nothing in this PR affects it; it needs the credentials rotated.