Closed kleinschmidt closed 10 months ago
Here is my theory on what is happening:
When add-julia-registry
is used before julia-actions/cache
the former action creates Git clones of a private registry and the General registry. When the Julia cache action runs, with registry caching enabled, a simple tarball extraction occurs which would modify the worktree of the registry clone. Once the Pkg.Registry.update
via Pkg.instantiate
through julia-actions/julia-runtest
the dirty worktree results in conflicts when trying to update the registry.
The reason this issue just started occurring recently is that registry caching is now on by default. This can be fixed having the cache step occur before add-julia-registry
or using the option cache-registries: false
with the Julia cache action (not recommended).
One option to transparency fix this would be to automatically exclude the registry directory from the cache when we detect existing content in the registry dir. This also means that the registry isn't saved into the cache. If the user swaps the order of the cache
/add-julia-registry
actions so caching is first then the cache-registry
option is once again enabled but initially there will be no cached registry. The add-julia-registry
will once again clone the registries and these registries will be saved into the cache for future use.
I validated my theory in #102 and implemented the transparent fix for this.
This has happened on two Beacon repos where we use
add-julia-registry
to add our private registry. Ifjulia-actions/cache
is run after that, then onPkg.test
we get errors like this:that goes away when we remove the cache action, and it goes away if we run the cache action before
add-julia-registry
.