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

V3 setup-dotnet ADR #291

Merged
merged 6 commits into from
Sep 14, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Rework
Vladimir Safonkin committed Sep 11, 2022
commit 2d9def70671f9768f130a1750b8e76d056968671
9 changes: 1 addition & 8 deletions docs/adrs/v3-setup-dotnet.md
Original file line number Diff line number Diff line change
@@ -17,13 +17,9 @@ The behavior is different for macOS runners because pre-installation directory m

- .NET supports installing and using multiple versions of .NET SDK and .NET runtime side-by-side. .NET CLI will use the latest installed .NET SDK and .NET runtime versions if there is no global.json file containing a different version. This behavior is defined by .NET design (https://docs.microsoft.com/en-us/dotnet/core/versions/selection).

- The action contains logic to handle inputs with wildcards, for example `5.0.x`, `5.0.*`, `5.x` or `5.*`. This logic uses metadata from `https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/releases-index.json` to retrieve the list of available releases and get the latest release version for the specified major and/or minor version from input. After that, installer script (`dotnet-install.ps1` for Windows or `dotnet-install.sh` for Linux and MacOS) installs the required SDK using exact version as a parameter.

# Proposal
- Change .NET installation path for Windows and Ubuntu images to match the location of pre-installed versions by using `-InstallDir` (Windows) and `--install-dir` (Ubuntu) properties for installer scripts:
https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script
- Get rid of redundant logic to resolve wildcard version on the action side and start relying on [official installer scripts provided by .NET Core team](https://github.com/dotnet/install-scripts).
The execution `dotnet-install.ps1 -Channel 5.0` installs the latest patch version for 5.0 sdk. In this way we can handle inputs with wildcard as patch version (`5.0.x` or `5.0.*`) by passing major and minor version to installer script directly as `channel` parameter. This parameter supports two-part version in X.Y format as input values ([see installer scripts documentation](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script)). Furthermore, the version input format of action will follow the format which is supported by installers scripts.

# Breaking changes
- The presence of pre-installed .NET versions that are higher than version that the users specify in the setup task can be breaking for some customers, who expect only one installed .NET version on runner after using the setup task. If user doesn't have .NET version specified in project file, `dotnet` will use the latest installed version instead of provided in the setup task.
@@ -32,8 +28,6 @@ Previously, when a user would specify a .NET version, this exact version was use
In proposal, the specified version will be installed on machine but the latest version will be used by `dotnet` command by default (because specified version will be installed alongside with pre-installed .NET versions).
Based on [official .NET documentation](https://docs.microsoft.com/en-us/dotnet/core/versions/selection), it is expected behavior and how it works on user's local machine with multiple installed .NET versions but some customers could be broken because they already rely on current behavior.

- All possible inputs will continue to work as previously except `5.x`. It is totally okay to drop it because we shouldn't allow users to rely on such input. The new minor release of .NET will break their builds.

To avoid breaking customers, we will need to release a new major task version (V3).

# v3-preview
@@ -44,5 +38,4 @@ There will be a v3-preview branch that will be created for development and testi
- Starter-workflow yamls: [#1](https://github.com/actions/starter-workflows/blob/main/ci/dotnet.yml#L17), [#2](https://github.com/actions/starter-workflows/blob/main/ci/dotnet-desktop.yml#L72)

# Consequences
- Customers will be able to use pre-installed .NET versions with setup-dotnet action on Windows and Ubuntu
- Maintenance of the action will be easier due to the simplier logic of handling inputs with wildcards
- Customers will be able to use pre-installed .NET versions with setup-dotnet action on Windows and Ubuntu