Bring the GitHub Actions up to date, and let Dependabot keep them there - #248
Merged
Conversation
Nothing here had been bumped since it was written, and two of the actions had
aged past working.
`julia-actions/cache@v1` speaks a cache-service API GitHub has retired, so every
job logged
##[warning]Failed to restore: Cache service responded with 400
Cache not found for input keys: julia-cache;workflow=CI;job=test;...
and CI has been running with no dependency cache at all — every job rebuilding
and re-precompiling the whole tree from scratch. And the runners were force-
migrating `actions/checkout@v4`, `julia-actions/setup-julia@v1` and the cache
action's bundled `actions/cache` off Node 20, which is on a deprecation clock.
Three of the pins were `@latest`, which is not a moving alias — it is a literal
tag, and neither upstream still moves theirs. `julia-actions/setup-julia@latest`
is a commit from November 2024 matching no release, and
`julia-actions/RegisterAction@latest` one from November 2022, older than that
action's own v0.3.2. Both read as if they track upstream and do not.
actions/checkout v4, v3 -> v7
actions/upload-artifact v4 -> v7
julia-actions/setup-julia v1, @latest -> v3
julia-actions/cache v1 -> v3
codecov/codecov-action v3 -> v7
julia-actions/RegisterAction @latest -> v0.3.2
`julia-buildpkg`, `julia-runtest`, `julia-processcoverage`, `julia-docdeploy`
and `TagBot` are all still on their current major.
Two behaviour changes come with this.
The `arch: x64` matrix pin is gone. `macOS-latest` is aarch64, and setup-julia v3
refuses `x64` there unless `force-arch` is set, because that build runs under
Rosetta — which is not the platform anyone deploys on. Each runner now gets its
native architecture, and the job name loses its `- x64` component. Nothing
required those names: `main`'s branch protection lists no required status checks.
`cache-registries: false`, against the action's default. The registry is the one
part of the depot that must not persist between runs. The package server's
General snapshot already lags the registry by hours — a run at 08:01 UTC today
still reported `AbstractNeuralNetworks ... possible versions are: 0.1.0 - 0.6.4`
four hours after 0.7.0 was registered — and caching it on top of that would keep
a freshly registered dependency invisible to CI for days. Artifacts, packages,
compiled code and scratchspaces are still cached, which is where the time goes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There is no `JULIA_PKG_SERVER` that works. Every official mirror — us-east, us-west, eu-central, jp, sg, kr, in, au — serves the identical registry tree, in both the conservative and the eager flavour, and so do the third-party storage mirrors (tuna, nju, bfsu). Checked this morning they were all on `4ead4e5d`, which is General as of 18:04 the previous evening: fifteen hours behind, and hours after `AbstractNeuralNetworks` 0.7.0 (04:00), `NeuralNetworkParameters` 0.1.1 (04:12) and `GeometricOptimizers` 0.4.1 (06:10) were registered. The lag is at the single storage server they all pull from, not at the edges, so picking a different one changes nothing. Cloning General over git is the only thing that sees a version the moment it is registered, and it is what #246 needs to resolve at all. The clone costs a fetch of the registry per job; against jobs that currently cannot resolve, that is worth paying. `JULIA_PKG_SERVER` itself is deliberately left alone. Unsetting it would route package tarballs off the CDN as well, which is not wanted — only the registry needs to bypass it. Verified locally: with General added by URL, `Pkg.pkg_server()` is still `https://pkg.julialang.org`, and `Pkg.add(name = "AbstractNeuralNetworks", version = "0.7")` resolves and installs 0.7.0. `julia-buildpkg` calls `Pkg.Registry.add()` on Julia >= 1.8, which installs the default registries only when none are present, so the step lands before it and nothing is duplicated — confirmed against a depot that already had the git clone. Added to `CI.yml`, `Documenter.yml` and `Latex.yml`, the three workflows that resolve. `cache-registries` stays false: a restored registry would only shadow the fresh clone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Same effect as the explicit `Pkg.Registry.add(RegistrySpec(url = ...))` step this replaces — both end up cloning General over git — but it is the idiom the sibling repo already runs, it is one `env:` block rather than a step per workflow, and it needs no reasoning about where it sits relative to `julia-buildpkg`'s own `Pkg.Registry.add()`. The objection to it was that an empty `JULIA_PKG_SERVER` routes package tarballs off the CDN as well, not just the registry. Measured, that costs nothing worth having: the registry clone is 68 s and 275 MB either way (it is the same git clone), and installing `HDF5` with its jll artifacts took 8.8 s without a package server against 10.1 s with one. The CDN is not carrying the weight here. `arch: default` comes back with it, again matching SymbolicNeuralNetworks — the previous commit had dropped the matrix dimension entirely to get off `x64` on aarch64 macOS, which also dropped the arch component from every job name. `default` is the runner's own architecture and keeps the names. `cache-registries: false` stays, which is the one deliberate difference from the sibling repo. `julia-actions/cache` saves the depot at the end of a job and restores it at the start of the next, so a cached registry is whatever the previous run cloned — for a repo whose CI runs a few times a day that is the same staleness this commit is working around, reintroduced through the back door. Everything else in the depot is still cached. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #248 +/- ##
=======================================
Coverage 66.80% 66.80%
=======================================
Files 99 99
Lines 2931 2931
=======================================
Hits 1958 1958
Misses 973 973 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
github-project-automation
Bot
moved this to Done
in Geometric Machine Learning Development
michakraus
added a commit
that referenced
this pull request
Aug 23, 2026
The four upstream releases this one's `[compat]` points at are all in the General registry as of 2026-08-23 — `AbstractNeuralNetworks` 0.7.0 at 04:00 UTC, `NeuralNetworkParameters` 0.1.1 at 04:12, `GeometricOptimizers` 0.4.1 at 06:10 and `SymbolicNeuralNetworks` 0.6.0 at 16:11. The *Merge order* note said the last of those was outstanding and that CI failing at `Pkg.instantiate` was expected; both are spent, so it is replaced by what actually resolves. Verified locally: `Pkg.update()` against the git registry takes ANN 0.7.0, NNP 0.1.1, GO 0.4.2 and SNN 0.6.0 with nothing `dev`'d, and LazyArrays floats from 2.3.2 to 2.12.0 — which is the `"=2.3.2"` pin's removal doing what the entry for it claims. The section also gains a preamble, in the shape 0.5.0's has: the parameter container moving out to its own package, Zygote 0.7 as the other half, and the three exports that go. Two changes the section did not mention, both infrastructure rather than package, now have entries: the GitHub Actions bumps of #248 — including that `julia-actions/cache@v1` had left CI with no dependency cache at all, and that dropping the `arch: x64` pin renames every job — and the `JULIA_PKG_SERVER=""` registry workaround. That one is still needed: the served snapshot (`4ead4e5df816`) stops at `AbstractNeuralNetworks` 0.6.4 and `SymbolicNeuralNetworks` 0.5.0, both excluded by this release's bounds. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
Nothing in
.github/workflows/had been bumped since it was written, and two of the actions hadaged past working.
What was broken
The cache never restored.
julia-actions/cache@v1speaks a cache-service API GitHub hasretired, so every job logged
CI has been running with no dependency cache at all — every job rebuilding and re-precompiling the
whole tree from scratch.
Node 20 was being force-migrated. The runners reported
actions/checkout@v4,julia-actions/setup-julia@v1and the cache action's bundledactions/cacheas targeting Node 20and being forced onto Node 24.
Three pins were
@latest, which is not a moving alias. It is a literal tag, and neitherupstream still moves theirs:
julia-actions/setup-julia@latestis a commit from 2024-11-18 matchingno release, and
julia-actions/RegisterAction@latestone from 2022-11-30 — older than that action'sown v0.3.2. Both read as if they track upstream and do not.
Bumps
actions/checkoutactions/upload-artifactjulia-actions/setup-julia@latest(Documenter, Latex)julia-actions/cachecodecov/codecov-actionjulia-actions/RegisterAction@latestjulia-buildpkg,julia-runtest,julia-processcoverage,julia-docdeployandTagBotare allstill on their current major and unchanged.
Two behaviour changes
The
arch: x64matrix pin is gone.macOS-latestis aarch64, and setup-julia v3 refusesx64there unless
force-archis set, because that build runs under Rosetta — not the platform anyonedeploys on. Each runner now gets its native architecture, and the job name loses its
- x64component. Nothing required those names:
main's branch protection lists no required status checks.cache-registries: false, against the action's default — see below. Artifacts, packages,compiled code and scratchspaces are still cached, which is where the time goes.
Dependabot
.github/dependabot.ymlwatchesgithub-actionsweekly, one PR per action so that a major needinga workflow change alongside it can be reviewed on its own. Julia dependencies are not included —
Dependabot has no Julia ecosystem, and
CompatHelper.ymlalready opens those nightly.The registry lag
The
[compat]failures on #246 are a stale General snapshot on the Julia package server. There isno
JULIA_PKG_SERVERthat avoids it — every official mirror serves the identical tree, in bothflavours, and so do the third-party storage mirrors:
registries.conservativeregistries.eager4ead4e5d4ead4e5d4ead4e5d81bd456d4ead4e5dis General as of 18:04 the previous evening — fifteen hours behind, and hours afterAbstractNeuralNetworks0.7.0 (04:00),NeuralNetworkParameters0.1.1 (04:12) andGeometricOptimizers0.4.1 (06:10) were registered. The lag is at the single storage server theyall pull from, not at the edges.
So
CI.yml,Documenter.ymlandLatex.ymlnow add General by git URL before anything resolves:JULIA_PKG_SERVERis deliberately left alone — unsetting it would route package tarballs off theCDN too, and only the registry needs to bypass it. Verified locally: with General added this way,
Pkg.pkg_server()is stillhttps://pkg.julialang.organdPkg.add(name = "AbstractNeuralNetworks", version = "0.7")resolves and installs 0.7.0.julia-buildpkgcallsPkg.Registry.add()on Julia ≥ 1.8, which installs the default registriesonly when none are present, so this step wins and nothing is duplicated — confirmed against a depot
that already had the clone.
The cost is a registry fetch per job, which is why
cache-registriesis false: a restored copywould only shadow the fresh clone.
🤖 Generated with Claude Code