-
Notifications
You must be signed in to change notification settings - Fork 470
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
Comments
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. |
cc @livarcocc (dev lead for .NET Core SDK/CLI) This seems reasonable to me, too. There can be multiple |
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. |
@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. |
+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. |
@roji 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. |
@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. |
@ZEisinger |
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 Here are the logs from the setup-dotnet step:
The PR with the relevant code and setup: npgsql/efcore.pg#1115. |
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 |
Global.json is the fall back method now and will go out with the next version |
Is this now released? Should the README be updated to list this capability? |
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:
I tried with act locally and it worked, the .NET 6 SDK (which is defined in my global.json file) was installed:
Here's my problematic GitHub Actions run. Reading the source code makes it clear that the version should be read from the 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? |
It was a dumb mistake: the The documentation could still be updated, though. |
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.
The text was updated successfully, but these errors were encountered: