I'm seeing a regression in 2.8.1 version. 2.8.0 works well.

The problem appears to be in how environment variables are setup when calling cargo. Previously the environment variables set in the workflow when using Swatinem/rust-cache action were active when cargo is executed but in 2.8.1 they are not.

I looked into the code and debug output and I can see that the problem lies here between these two debug messages: https://github.com/Swatinem/rust-cache/blob/master/src/workspace.ts#L14-L21

      core.debug(`collecting metadata for "${this.root}"`);
      const meta: Meta = JSON.parse(
        await getCmdOutput("cargo", ["metadata", "--all-features", "--format-version", "1", ...extraArgs], {
          cwd: this.root,
          env: { "CARGO_ENCODED_RUSTFLAGS": "" },
        }),
      );
      core.debug(`workspace "${this.root}" has ${meta.packages.length} packages`);

I noticed that the env field there on line 18 is new in 2.8.1 from this PR: https://github.com/Swatinem/rust-cache/pull/249/files

I traced how the cargo actually gets executed by @actions/exec and it matches what I observed the behaviour to be:

• it first locates the executable cargo using which: https://github.com/actions/toolkit/blob/b820a0ff5913eee855292f1c0148a78ac2bd5887/packages/exec/src/toolrunner.ts#L417
  • that still uses the current process environment and ignores the options.env parameter from rust-cache so PATH environment variable value from workflow step is honored and cargo executable is found
• it then initialises the environment for execution by using options.env if specified and otherwise using process.env
  • when process.env is specified, the current process environment is ignored

Could that execution be changed so that it would copy the current process environment and amend that with the CARGO_ENCODED_RUSTFLAGS?
Or is there a reason why that call should use explicitly empty environment instead of allowing users of rust-cache action to use their own environment variables?

Note that it also causes environment variables for cargo itself like CARGO_HOME to be ignored. I think that one at least would be quite important for cargo to operate properly.

In my case cargo fails to work as I have it installed through mise and mise needs few extra environment variables in order to run correct cargo binary.