Packages lock file and cache mode

[alexeyzimarev]

Description: It might the documentation issue as it's very sparse concerning the cache mode. I have a relatively large repository with one solution, and tens of projects. I enabled restore using the lock file, and now every project directory contains the packages.lock.json file. However, when running setup-dotnet@v3 with cache: true, I get the following error message:

Dependencies lock file is not found in /home/runner/work/eventuous/eventuous. Supported file patterns: packages.lock.json

The docs say roughly the same that the action will look for the lock file in the repository root, but NuGet lock files aren't in the repo root, they are in each project directory. How does it suppose to work?

Task version: v3

Platform:

• [x] Ubuntu
• [ ] macOS
• [ ] Windows

Runner type:

• [x] Hosted
• [ ] Self-hosted

Repro steps:

• Create a solution with multiple projects
• Enable lock file for NuGet restore
• Commit packages.lock.json files (there will be one per project)
• Try using cache: true with setup-dotnet
• Workflow fails

Repository: https://github.com/Eventuous/eventuous Failed workflow: https://github.com/Eventuous/eventuous/actions/runs/6363625672

Expected behavior: NuGet dependencies cached based on the lock files.

Actual behavior: Action can't find the lock file in the repository root, where it should not be.

[dusan-trickovic]

Hello, @alexeyzimarev ! Thank you for reporting this issue, we will take a look and see what can be done :)

[dusan-trickovic]

Hello again, @alexeyzimarev! Regarding the resolution to your problem, have you tried setting up cache-dependency-path in your workflow, along with cache: true?

The example of what I mean by that would be something like:

- name: Setup .NET
  uses: actions/setup-dotnet@v3
  with:
     dotnet-version: '3'
     cache: true
     cache-dependency-path: '**/package-lock.json'

In case package-lock.json (which is, as the error message in the logs says, the supported file pattern) isn't directly accessible in the root of your project (or in case you have nested subdirectories within your project with their individual dependency files), you would need to use cache-dependency-path to specify where those lock.json files are located. You can find more on advanced usage of caching in setup-* action workflows here

Using the wildcard as described above would recursively detect all package-lock.json files across your entire project. Of course, you could also list them one by one inside your workflow with their relative paths if you so prefer.

If you have any further questions, concerns or suggestions, please feel free to let us know. Additionally, if this suggestion solved your issue, feel free to let us know about it as well :)

Thank you for your time and cooperation!

[dusan-trickovic]

Hello, @alexeyzimarev! I just wanted to give you a gentle ping and see if there are any updates on your end regarding this issue? Thank you :)

[alexeyzimarev]

Sorry, I am going through GH notifications only now and then, just got your message. No, I haven't tried to set up the path as I thought (after reading the docs), it only expects to get one file, not a mask.

I will try the mask during the weekend.

[snwflake]

Same issue here. workflow bit:

      - name: Setup dotnet
        uses: actions/setup-dotnet@v3
        with:
          global-json-file: global.json
          cache: true
          cache-dependency-path: project_containing_lockfile/packages.lock.json

with error: Dependencies lock file is not found in /home/runner/work/Solution/project_containing_lockfile. Supported file patterns: packages.lock.json

[usagiga]

I got a same issue, but it was resolved soon after trying the @dusan-trickovic approach like these:

steps:
  # Initializing Build Environments
  - uses: actions/checkout@v4
  - uses: actions/setup-dotnet@v4
    with:
      dotnet-version: 8.x
      cache: true
      cache-dependency-path: '**/packages.lock.json'

Logs on GitHub Actons as below:

Run actions/setup-dotnet@v4
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --runtime dotnet --channel LTS
dotnet-install: .NET Core Runtime with version '8.0.0' is already installed.
/home/runner/work/_actions/actions/setup-dotnet/v4/externals/install-dotnet.sh --skip-non-versioned-files --channel 8.0
dotnet-install: .NET Core SDK with version '8.0.100' is already installed.
Received 4194304 of 82152453 (5.1%), 4.0 MBs/sec
Cache Size: ~78 MB (82152453 B)
/usr/bin/tar -xf /home/runner/work/_temp/662dbaea-02e4-4582-b4ee-465353b69717/cache.tzst -P -C /home/runner/work/foo/foo --use-compress-program unzstd
Received 82152453 of 82152453 (100.0%), 39.2 MBs/sec
Cache restored successfully
Cache restored from key: dotnet-cache-Linux-xxx

Thank you! 👍

[PureKrome]

Just stumbled onto this issue also.

I have both the setup-dotnet@v4 (with the cache:true) setting and this error occured.

I also have the actions/cache action after this but before my dotnet restore for caching the nuget's.

Is this cache:true command a weird thing which caches:

• the .NET runtime
• the nugets when we do a dotnet restore?

if YES or NO, then the documentation is not clear about this at all and could do with a little update.

Also, I'd love to know if the cache:true does both the .NET runtime and nugets.