Comments (15)
Global.json is the fall back method now and will go out with the next version
from setup-dotnet.
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.
from setup-dotnet.
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
from setup-dotnet.
@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.
from setup-dotnet.
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.
from setup-dotnet.
@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.
from setup-dotnet.
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
from setup-dotnet.
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.
from setup-dotnet.
@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.
from setup-dotnet.
+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.
from setup-dotnet.
from setup-dotnet.
@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.
from setup-dotnet.
Is this now released? Should the README be updated to list this capability?
from setup-dotnet.
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?
from setup-dotnet.
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.
from setup-dotnet.
Related Issues (20)
- Problem matcher does not work with normal verbosity HOT 5
- Dotnet version looking for a version that is not available HOT 1
- All dotnet commands fail due to environment variables HOT 6
- .NET Test invoking an Azure Function: An error occurred trying to start process 'func' with working directory. The system cannot find the file specified. HOT 6
- .NET MAUI IOS HOT 4
- Share this site HOT 1
- Fallback to different installation directory if `/usr/share/dotnet` doesn't available due to permissions HOT 4
- Allow control of the noCdn / no_cdn script parameters HOT 1
- Unauthorised when using `secrets.GITHUB_TOKEN`. Packages not pushed to Github Repository Packages when using PAT. HOT 9
- Add a possibility to specify the verbosity flag for the install-scripts execution HOT 1
- Support SDK workloads HOT 2
- Support explicit architecture for dotnet HOT 1
- Allow tools to cache
- NUGET_AUTH_TOKEN does not work for official NuGet repository HOT 8
- Docs Bug: v4 README points to v3 HOT 2
- Bitcoin HOT 1
- Infrequent "MSB4236: The SDK 'Microsoft.NET.Sdk.Web' specified could not be found" errors with ubuntu 24.04 hosted runner. HOT 7
- cache-dependency-path does not support list of file names, but in description it's said, thay it can HOT 4
- Installed version of .NET not respected. HOT 8
- Automatically auth package source mapping that match source-url HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from setup-dotnet.