Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Install sdk from global.json #14

Closed
xt0rted opened this issue Aug 11, 2019 · 15 comments
Closed

Install sdk from global.json #14

xt0rted opened this issue Aug 11, 2019 · 15 comments
Assignees

Comments

@xt0rted
Copy link

xt0rted commented Aug 11, 2019

In the root of the repo there can be a global.json that specifies the sdk version required to build. Checking this automatically (maybe via a switch you can turn on and off?) would simplify setup so if you're using a version not already installed, such as a pre-release, the sdk will automatically be installed and you don't have to maintain a version number in there and the workflow file.

@damccorm
Copy link
Contributor

damccorm commented Aug 12, 2019

I think we should do this. My inclination is to try to read from version first - if no version is supplied then fall back to the global.json. We can add an option to turn that behavior off down the line if needed, but I don't see a use case for that for now at least.

@rainersigwald
Copy link
Contributor

cc @livarcocc (dev lead for .NET Core SDK/CLI)

This seems reasonable to me, too. There can be multiple global.json files in a repo, which could lead to some confusion. I do not think that this should search, but as an on-rails default, respecting /global.json sounds great, and would reduce the duplication required specifying version in both places.

@livarcocc
Copy link

There is an issue filled for this on the CLI to support the global.json from the dotnet-install scripts: https://github.com/dotnet/cli/issues/12175.

We don't really support multiple global.json files in a solution/repository. It can lead to multiple versions of the SDK's targets/tasks being loaded (or needing to be loaded). So, if you do that, you are definitely in a unsupported scenario.

If you care about this scenario for the install scripts, please comment on the issue I linked above.

@chrispat
Copy link
Member

chrispat commented Sep 5, 2019

@livarcocc I commented on the issue. I would prefer to see the installer script read the global.json rather than us implmenting the fallback in the action.

@roji
Copy link

roji commented Nov 1, 2019

+1 to this, hopefully it can be done soon (especially as dotnet/cli#12750 has already been done).

One more thought on this - if the SDK being requested (whether on the cmdline or in the global.json) happens to already be installed on the system, the action could detect that and do nothing, saving download and installation times. I can open a separate issue for that.

@livarcocc
Copy link

@johnbeisner

@johnbeisner
Copy link

@roji
Support for version harvesting from a global.json has been deployed: https://github.com/dotnet/dotnet-website/pull/1602

Let me know how I can assist you in getting this working in your scenario.

BTW: if the SDK being requested happens to already be installed; the scripts do indeed skip the download and installation.

@ZEisinger
Copy link
Contributor

@johnbeisner Thanks John, I will work on getting this set-up to run.

If the scripts handle caching already, I will remove all the caching built into this task to use a separate folder structure. Which will solve #25 and the above concern.

@johnbeisner
Copy link

@ZEisinger
"If the scripts handle caching already" - To be clear - if you have installed an SDK at a particular version to a particular location, if you try to install the same SDK version to the same location - the script will detect this and skip the download and install. I don't see this as "caching" per se; it feels more like removing redundant steps.

@roji
Copy link

roji commented Nov 6, 2019

This doesn't seem to be working for me (or I may be misunderstanding something). I have a setup-dotnet step:

- name: Setup .NET Core SDK
  uses: actions/setup-dotnet@e1b1954735348cd3b65a85ba6659d01f785b970f

- name: Test
  run: dotnet test --configuration Debug
  shell: bash

There's a global.json at the root specifying 3.1.100-preview1-014459, but the test step fails with A compatible installed .NET Core SDK for global.json version [3.1.100-preview1-014459] from [/home/runner/work/efcore.pg/efcore.pg/global.json] was not found.

Here are the logs from the setup-dotnet step:

2019-11-06T11:11:18.9298774Z ##[group]Run actions/setup-dotnet@e1b1954735348cd3b65a85ba6659d01f785b970f
2019-11-06T11:11:18.9298911Z with:
2019-11-06T11:11:18.9298990Z ##[endgroup]
2019-11-06T11:11:22.1125440Z ##[warning]Use the v1 tag to get the last version, master may contain breaking changes and will not contain any required packages in the future. i.e. actions/setup-dotnet@v1
2019-11-06T11:11:22.1170170Z Added matchers: 'csc'. Problem matchers scan action output for known warning or error strings and report these inline.
2019-11-06T11:11:22.1170318Z ##[add-matcher]/home/runner/work/_actions/actions/setup-dotnet/e1b1954735348cd3b65a85ba6659d01f785b970f/.github/csc.json
2019-11-06T11:11:22.1703642Z ##[group]Run dotnet test --configuration Debug
2019-11-06T11:11:22.1703884Z �[36;1mdotnet test --configuration Debug�[0m
2019-11-06T11:11:22.1733248Z shell: /bin/bash --noprofile --norc -e -o pipefail {0}
2019-11-06T11:11:22.1733528Z ##[endgroup]

The PR with the relevant code and setup: npgsql/efcore.pg#1115.
Failed build: https://github.com/npgsql/efcore.pg/commit/b63358e30ef8f4097ad37fde3a28c015406ca35b/checks?check_suite_id=298213494

@RehanSaeed
Copy link

This would be really nice. The Azure DevOps task does it like this:

- task: UseDotNet@2
      displayName: 'Install .NET Core SDK'
      inputs:
        packageType: 'sdk'
        useGlobalJson: true

@ZEisinger
Copy link
Contributor

Global.json is the fall back method now and will go out with the next version

@RehanSaeed
Copy link

Is this now released? Should the README be updated to list this capability?

@0xced
Copy link

0xced commented Dec 12, 2021

I just tried to not specify a version in the yml file like this:

- name: Install .NET SDK
  uses: actions/setup-dotnet@v1

Unfortunately, the action did noting!

Here's the full log:

2021-12-12T23:33:15.6443929Z ##[group]Run actions/setup-dotnet@v1
2021-12-12T23:33:15.6444747Z with:
2021-12-12T23:33:15.6445130Z env:
2021-12-12T23:33:15.6445573Z   Configuration: Release
2021-12-12T23:33:15.6446396Z   ContinuousIntegrationBuild: true
2021-12-12T23:33:15.6447392Z   DOTNET_CLI_TELEMETRY_OPTOUT: true
2021-12-12T23:33:15.6447913Z   DOTNET_NOLOGO: true
2021-12-12T23:33:15.6448419Z   DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
2021-12-12T23:33:15.6448920Z ##[endgroup]

I tried with act locally and it worked, the .NET 6 SDK (which is defined in my global.json file) was installed:

[Continuous Integration/Run tests and create NuGet package-2           ] ⭐  Run Install .NET SDK
INFO[0021]   ☁  git clone 'https://github.com/actions/setup-dotnet' # ref=v1 
[Continuous Integration/Run tests and create NuGet package-2           ]   🐳  docker cp src=/Users/0xced/.cache/act/actions-setup-dotnet@v1/ dst=/var/run/act/actions/actions-setup-dotnet@v1/
[Continuous Integration/Run tests and create NuGet package-2           ]   🐳  docker exec cmd=[mkdir -p /var/run/act/actions/actions-setup-dotnet@v1/] user= workdir=
[Continuous Integration/Run tests and create NuGet package-2           ]   🐳  docker exec cmd=[node /var/run/act/actions/actions-setup-dotnet@v1/dist/index.js] user= workdir=
[Continuous Integration/Run tests and create NuGet package-2           ]   💬  ::debug::No version found, trying to find version from global.json
| [command]/run/act/actions/actions-setup-dotnet@v1/externals/install-dotnet.sh --version 6.0.100
| dotnet-install: Note that the intended use of this script is for Continuous Integration (CI) scenarios, where:
| dotnet-install: - The SDK needs to be installed without user interaction and without admin rights.
| dotnet-install: - The SDK installation doesn't need to persist across multiple CI runs.
| dotnet-install: To set up a development environment or to run apps, use installers rather than this script. Visit https://dotnet.microsoft.com/download to get the installer.
| 
| dotnet-install: Downloading primary link https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.100/dotnet-sdk-6.0.100-linux-x64.tar.gz
| dotnet-install: Extracting zip from https://dotnetcli.azureedge.net/dotnet/Sdk/6.0.100/dotnet-sdk-6.0.100-linux-x64.tar.gz
| dotnet-install: Adding to current process PATH: `/root/.dotnet`. Note: This change will be visible only when sourcing script.
| dotnet-install: Note that the script does not resolve dependencies during installation.
| dotnet-install: To check the list of dependencies, go to https://docs.microsoft.com/dotnet/core/install, select your operating system and check the "Dependencies" section.
| dotnet-install: Installation finished successfully.
| /root/.dotnet:/opt/hostedtoolcache/node/14.18.2/x64/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Here's my problematic GitHub Actions run.

Reading the source code makes it clear that the version should be read from the global.json file but nothing happens.

let versions = core.getMultilineInput('dotnet-version');
if (!versions.length) {
  // Try to fall back to global.json
  core.debug('No version found, trying to find version from global.json');
  const globalJsonPath = path.join(process.cwd(), 'global.json');
  if (fs.existsSync(globalJsonPath)) {
    versions.push(getVersionFromGlobalJson(globalJsonPath));
  }
}

Am I missing something?

@0xced
Copy link

0xced commented Dec 13, 2021

It was a dumb mistake: the actions/setup-dotnet@v1 action must be run after the actions/checkout@v2 action for the global.json file to be available! So everything works as expected when used correctly.

The documentation could still be updated, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

10 participants