Disable cache copy or use cache as is without creation new

[coolassassin]

Hello!

We are using NX in our team for a long time and few months ago we have migrated to new version, with new cache flow.
After setup we have found that running task in CI we have an error:
The local cache artefact in "/<redacted>/node_modules/.cache/nx/<redacted>" was not been generated on this machine.
Then we find out that we can fix it easily by adding NX_REJECT_UNKNOWN_LOCAL_CACHE=0 to environment and it fixed the issue.
But, now we have another one.
When we make build first we have no cache, but after build we save it for future builds.
Next build will take the cache and by NX_REJECT_UNKNOWN_LOCAL_CACHE will ignore that this cache from another machine and will use it.
But, after build we will have new cache. The copy of first and new one.
As result we have infinitely growing cache artefact, because we have a lot of agents(machines) in our CI infrastructure.

I didn't try, but i can imagine some workarounds:

1. After build I can find all artefacts which has source file with wrong machine-id and erase them.
2. Instead of using NX_REJECT_UNKNOWN_LOCAL_CACHE, I can go through cache and replace all source files with id of my machine

Theoretically both ways has to fix my issue, but it seems weird to write custom scripts based on internal implementation of NX, which can change in next releases

Could you help me to find a right way to solve this issue

[jaysoo]

@coolassassin It sounds like you're using a shared drive, which is not recommended due to potential security risks.

However, if you do need to use shared drives, then I would recommend adding environment or runtime inputs to your build tasks.

For example, in your nx.json you could update your production named inputs to something like this:

{
  "$schema": "packages/nx/schemas/nx-schema.json",
  "namedInputs": {
    "default": ["{projectRoot}/**/*", "sharedGlobals"],
    "production": [
      "default",
      "!{projectRoot}/**/?(*.)+(spec|test).[jt]s?(x)?(.snap)",
      ...
      { "env": "GITHUB_RUN_ID" },
      { "ruintime": "node --version" },
      { "runtime": "hostname" }
    ],
    ...
  },
  ...
}

In the above example, the GITHUB_RUN_ID from GitHub actions will be unique for each workflow run. The runtime inputs will use the result of node --version and hostname commands as inputs. These are just examples, you should customize them to suit your needs.