.NET installations are not being cached

[GGG-KILLER]

Description

.NET installations aren't being cached even when the same version remains the same between workflow runs.

Details

I have a workflow that uses .NET Core 2.1, 3.1 and 5.0 side-by-side and it has been downloading and installing these versions even when they haven't changed in different workflow runs:

# workflow.yml
name: Test

on: [push, pull_request]

jobs:
  build:
    name: Build and Test on ${{ matrix.os }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    steps:
    - uses: actions/checkout@v2
    - name: Setup .NET Core 2.1
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '2.1'
    - name: Setup .NET 3.1
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '3.1'
    - name: Setup .NET 5
      uses: actions/setup-dotnet@v1
      with:
        dotnet-version: '5.0.100-rc.1.20452.10'
    - name: Install dependencies
      run: dotnet restore
    - name: Build
      run: dotnet build --configuration Release --no-restore
    - name: Test
      run: dotnet test --configuration Release --no-build

3 runs with the same versions:

1. https://github.com/GGG-KILLER/GParse/runs/1328132497?check_suite_focus=true
2. https://github.com/GGG-KILLER/GParse/runs/1328139624?check_suite_focus=true
3. https://github.com/GGG-KILLER/GParse/runs/1328149289?check_suite_focus=true

In all of these runs the installation wasn't cached.

This seems to be a regression, since before this action started using install-dotnet.sh/install-dotnet.ps1 they were being cached and the README still states that the installed versions should be cached.

[litetex]

It seems like it was removed with #124:
c9bfd3d#diff-36a9847d245bd66dd946fe257334eb7bbe0c728d37d53df8b8173c7e3eecd5b2L160-L163

[r3econ]

Will this be fixed sometime soon?

[JustinGrote]

This should be updated to use the tool-cache package
https://github.com/actions/toolkit/tree/main/packages/tool-cache

[GGG-KILLER]

This should be updated to use the tool-cache package
https://github.com/actions/toolkit/tree/main/packages/tool-cache

The actual work is being done by the powershell/bash install-dotnet scripts though.
The actual action code just invokes the script with the right parameters (and at most does .NET version resolution).

[GGG-KILLER]

Though I guess cacheDir could be called with the directory where the versions were installed...

EDIT: Seems like cacheDir only works for self-hosted runners so I don't think this will help with GitHub-hosted runners.

[JustinGrote]

@GGG-KILLER you're right, my bad.
https://github.com/actions/toolkit/pull/358/files

I suppose it could be a composite action and integrate the actions/cache action but maybe that should be left up to the consumer instead.

[JustinGrote]

I'm not up on my news, v2 of the cache action has a cache npm package, so this could be directly used without needing to make a composite action:
https://github.com/actions/toolkit/tree/main/packages/cache

[GGG-KILLER]

Iirc, this package used to use the cache package, but after changing to the install-dotnet scripts this situation changed.
I think this could be reimplemented but then the package would need additional logic to check if the cached version is indeed the latest version when versions with placeholders are used (like 5.x or 5.0.x).

[alex-jitbit]

Any news?

[ghost]

• name: Setup .NET Core SDK
  uses: actions/[email protected]

[jetersen]

Seems like we could get caching working again relatively easy:

setup-dotnet/externals/install-dotnet.ps1

Line 1072 in 4997896

$isAssetInstalled = Is-Dotnet-Package-Installed -InstallRoot $InstallRoot -RelativePathToPackage $dotnetPackageRelativePath -SpecificVersion $SpecificVersion

setup-dotnet/externals/install-dotnet.sh

Line 1194 in 4997896

if is_dotnet_package_installed "$install_root" "$asset_relative_path" "$specific_version"; then

by fixing the InstallRoot to the same location as GitHub action runners for windows and ubuntu respectively. I believe MacOS is already using the correct caching location.

[GGG-KILLER]

Seems like we could get caching working again relatively easy:

setup-dotnet/externals/install-dotnet.ps1

Line 1072 in 4997896

$isAssetInstalled = Is-Dotnet-Package-Installed -InstallRoot $InstallRoot -RelativePathToPackage $dotnetPackageRelativePath -SpecificVersion $SpecificVersion

setup-dotnet/externals/install-dotnet.sh

Line 1194 in 4997896

if is_dotnet_package_installed "$install_root" "$asset_relative_path" "$specific_version"; then

by fixing the InstallRoot to the same location as GitHub action runners for windows and ubuntu respectively. I believe MacOS is already using the correct caching location.

That is not the reason why installations aren't being cached though. That's the reason why the preinstalled versions aren't being used. These are two separate issues.

Now that the hosted runner images aren't going to include .NET anymore, I think this is even more relevant as we won't be able to take advantage of .NET being preinstalled on the runners.

[jetersen]

Now that the hosted runner images aren't going to include .NET anymore

actions/runner-images#3809 latest patch for every feature version should still be installed. Why not combine preinstalled with caching?

I don't see it as separate issues.

[GGG-KILLER]

Now that the hosted runner images aren't going to include .NET anymore

actions/runner-images#3809 latest patch for every feature version should still be installed. Why not combine preinstalled with caching?

I don't see it as separate issues.

Actually they have said they don't plan to install newer versions of .NET for now: actions/runner-images#4424 (comment)

And this is still a different issue if a workflow needs a specific version of .NET or a version that is not preinstalled.

And it has been mentioned v2 of this action will use the correct installation paths for Windows and Linux.

[jetersen]

Sadly @miketimofeev statement is very vague and is not made as an announcement post, other users asked clarifying questions in the comments below that comment.

How about working with what we have now? We have several preinstalled .NET installation that can be considered as an cache that you potentially don't have to reinstall.

And this is still a different issue if a workflow needs a specific version of .NET or a version that is not preinstalled.

What's wrong with globaljson for specific version and using setup-dotnet to ensure that version is installed?
And of course if not installed the setup-dotnet should install it.

[GGG-KILLER]

What's wrong with globaljson for specific version and using setup-dotnet to ensure that version is installed?
And of course if not installed the setup-dotnet should install it.

That in subsequent runs, that version would not be cached in the runner thus having to be installed every single time, which depending on the amount of versions you have to install may be up to a minute.

Using the preinstalled versions is covered by #208.

[jacargentina]

not yet worked on? using a very slow internet here at home, downloading .net 7 every run....

maybe In my case I should use other docker image which already has .net 7 there, right?

[Danielku15]

I am also experiencing something related in our self-hosted runners. In my open source project on Github.com I can see that the script reports that .net is detected and not installed (after 3secs 🥳 ):

But on our self-hosted runner in our GitHub Enterprise Server where we have installed the latest .net SDK 7 on the system globally, the action installs the SDK again on every run (~2 minutes 😱):

We just do:

- uses: actions/setup-dotnet@v3
  with:
    dotnet-version: "7.0"

[IvanZosimov]

Hi, @Danielku15 👋 Thanks for the comment! Could you check that when you installed some exact version of the .NET sdk (let's say 7.0.306) via the action it also appears in the list formed by dotnet --list-sdks in the cmd on your enterprise server? Could you also provide us with the logs (with debug mode turned on - tutorial) of two subsequent runs that instruct setup-dotnet to install same version of .NET ?

[Danielku15]

Could you check that when you installed some exact version of the .NET sdk (let's say 7.0.306) via the action it also appears in the list formed by dotnet --list-sdks in the cmd on your enterprise server?

This is cmd screenshot above (3nd screenshot). We have installed 7.0.400 on the VM hosting the Actions Runner and it is listed in the SDKs. The same version is claimed to be installed in the logs of the runner (2rd screenshot).

Could you also provide us with the logs (with debug mode turned on - tutorial) of two subsequent runs that instruct setup-dotnet to install same version of .NET ?

I found the problem already. We had an environment variable DOTNET_INSTALL_DIR=${{ github.workspace }}/dotnet defined. After removing this (unintended) customization it works as expected.

I guess the system could still detect that a 7.0 is installed and use it, but that seems unnecessary complex considering the version wildcards.

Hopefully this insight helps others.

[VAllens]

However, even after I create the global.json file specifying that I want to use version 7.0, it still always installs the latest version(8.0), for me, before finally installing the version specified by the dotnet-version parameter(7.0) for me.
This is unnecessary, it wastes a lot of my time, especially with a slow network, and it doesn't seem to cache the installer packages and the install directory for me.

[VAllens]

Any news?

[Hooch180]

Any news?