I have an unfree package in a devshell defined in a project's flake.nix, and for each unique git tree (branch) that executes a pipeline that uses that devshell, the package is rebuilt from scratch. The package is uploaded to the cache successfully, but other trees will not ever benefit from this. Subsequent pipeline runs on the same tree seem to re-use the cached package as expected.
This causes a painfully slow pipeline for each new branch, and for merging if using a merge queue. I'm led to believe that the cache is indexed on the specific tree.
Is this expected behavior?
Is there a way to avoid this behavior, such as ensuring that cache is indexed by some other identifier than what is currently being used? For example, a common pattern when using the GHA cache is to set restore-keys to foo-bar-${{ hashFiles('flake.nix') }}ANDfoo-bar-. This lets the action/cache fall back. Can this kind of behavior be implicitly supported in this action?
For context, here's a snippet from my flake.nix showing the package and devshell:
I have an unfree package in a devshell defined in a project's
flake.nix
, and for each unique git tree (branch) that executes a pipeline that uses that devshell, the package is rebuilt from scratch. The package is uploaded to the cache successfully, but other trees will not ever benefit from this. Subsequent pipeline runs on the same tree seem to re-use the cached package as expected.This causes a painfully slow pipeline for each new branch, and for merging if using a merge queue. I'm led to believe that the cache is indexed on the specific tree.
restore-keys
tofoo-bar-${{ hashFiles('flake.nix') }}
ANDfoo-bar-
. This lets theaction/cache
fall back. Can this kind of behavior be implicitly supported in this action?For context, here's a snippet from my
flake.nix
showing the package and devshell:And the pipeline configuration: