From fb09b12527443b9e60ea60697de333aef881992f Mon Sep 17 00:00:00 2001 From: Vladimir Safonkin Date: Fri, 29 Apr 2022 11:22:26 +0200 Subject: [PATCH 1/6] v3 adr --- docs/adrs/v3-setup-dotnet.md | 48 ++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 docs/adrs/v3-setup-dotnet.md diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md new file mode 100644 index 000000000..ddb70905c --- /dev/null +++ b/docs/adrs/v3-setup-dotnet.md @@ -0,0 +1,48 @@ +# V3 setup-dotnet + +Date: 2021-06-30 +Status: Proposed + +# Context +- GitHub-hosted Ubuntu and Windows runners have .NET versions pre-installed in system directories + - Ubuntu:`/usr/share/dotnet` + - Windows:`C:\Program Files\dotnet` +- V1 version of Action installs .NET to user's directory + - Ubuntu:`/home/runner/.dotnet` + - Windows: `C:\Users\runneradmin\AppData\Local\Microsoft\dotnet` +- It means that action always download and install .NET version even if it is pre-installed. Also after using the action all pre-installed .NET versions are unavailable because `DOTNET_ROOT` is overriden to user directory. +The behavior is different for macOS runners because pre-installation directory matches the one that is used by action. It means action can use pre-installed versions if it exists, which speeds up customer's workflow. + +- The different behavior of setup task on Ubuntu, Windows and MacOS runners is unclear and confusing for customers. + +- .NET supports installing and using multiple versions of .NET SDK and .NET runtime sidy-by-side. .NET CLI will use the latest of installed .NET SDK and .NET runtime version 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 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) property 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 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)). In further 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 setup task. If user doesn't have .NET version specified in project file, `dotnet` will use the latest installed version instead of provided in setup task. +> **Note:** It is the biggest deal in this ADR. +Previously, when user specifies .NET version, this exact version was used by `dotnet` command by default (because it was installed in the separate folder and there are no any other .NET versions in that folder) +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 user to rely on such input. New minor release of .NET will break their builds + +To avoid breaking customers, we will need to release new major task version (V3). + +# v3-preview +There will be a v3-preview branch that will be created for development and testing. Any changes will first be merged into v3-preview branch. After a period of testing & verification, the v3-preview branch will be merged into the main branch and a v3 tag will be created. Any GitHub public documentation and starter workflows that mention setup-dotnet will then be updated to use v3 instead of v2: +- [README.md](https://github.com/actions/setup-dotnet/blob/main/README.md) +- [action.yml](https://github.com/actions/setup-dotnet/blob/main/action.yml) +- [GitHub docs](https://docs.github.com/en/actions/guides/building-and-testing-net#using-a-specific-net-version) +- 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 the simplier logic of handling inputs with wildcards \ No newline at end of file From d33e605efe06f08cf29ea1c2757d6cdc08644c8f Mon Sep 17 00:00:00 2001 From: Vladimir Safonkin Date: Wed, 24 Aug 2022 12:32:58 +0200 Subject: [PATCH 2/6] Grammar fixes --- docs/adrs/v3-setup-dotnet.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md index ddb70905c..7498a1573 100644 --- a/docs/adrs/v3-setup-dotnet.md +++ b/docs/adrs/v3-setup-dotnet.md @@ -10,31 +10,31 @@ Status: Proposed - V1 version of Action installs .NET to user's directory - Ubuntu:`/home/runner/.dotnet` - Windows: `C:\Users\runneradmin\AppData\Local\Microsoft\dotnet` -- It means that action always download and install .NET version even if it is pre-installed. Also after using the action all pre-installed .NET versions are unavailable because `DOTNET_ROOT` is overriden to user directory. -The behavior is different for macOS runners because pre-installation directory matches the one that is used by action. It means action can use pre-installed versions if it exists, which speeds up customer's workflow. +- It means that action always download and install .NET version even if it is pre-installed. Also after using the action all pre-installed .NET versions are unavailable because `DOTNET_ROOT` is overriden to user's directory. +The behavior is different for macOS runners because pre-installation directory matches the one that is used by action. It means action can use pre-installed versions if they exist, which speeds up customer's workflow. -- The different behavior of setup task on Ubuntu, Windows and MacOS runners is unclear and confusing for customers. +- The different behavior of the setup task on Ubuntu, Windows and MacOS runners is unclear and confusing for customers. -- .NET supports installing and using multiple versions of .NET SDK and .NET runtime sidy-by-side. .NET CLI will use the latest of installed .NET SDK and .NET runtime version 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). +- .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 required SDK using exact version as a parameter. +- 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) property for installer scripts: +- 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 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)). In further the version input format of action will follow the format which is supported by installers scripts. +- 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 setup task. If user doesn't have .NET version specified in project file, `dotnet` will use the latest installed version instead of provided in setup task. +- 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. > **Note:** It is the biggest deal in this ADR. -Previously, when user specifies .NET version, this exact version was used by `dotnet` command by default (because it was installed in the separate folder and there are no any other .NET versions in that folder) +Previously, when a user would specify a .NET version, this exact version was used by `dotnet` command by default (because it was installed in a separate folder and there were no other.NET versions in that folder) 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 user to rely on such input. New minor release of .NET will break their builds +- 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 new major task version (V3). +To avoid breaking customers, we will need to release a new major task version (V3). # v3-preview There will be a v3-preview branch that will be created for development and testing. Any changes will first be merged into v3-preview branch. After a period of testing & verification, the v3-preview branch will be merged into the main branch and a v3 tag will be created. Any GitHub public documentation and starter workflows that mention setup-dotnet will then be updated to use v3 instead of v2: @@ -45,4 +45,4 @@ There will be a v3-preview branch that will be created for development and testi # 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 the simplier logic of handling inputs with wildcards \ No newline at end of file +- Maintenance of the action will be easier due to the simplier logic of handling inputs with wildcards \ No newline at end of file From 4cb4764ae273a50fcf03926ad72109659248f6d8 Mon Sep 17 00:00:00 2001 From: Vladimir Safonkin Date: Mon, 29 Aug 2022 11:23:22 +0200 Subject: [PATCH 3/6] Update ADR date --- docs/adrs/v3-setup-dotnet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md index 7498a1573..fd0d556e6 100644 --- a/docs/adrs/v3-setup-dotnet.md +++ b/docs/adrs/v3-setup-dotnet.md @@ -1,6 +1,6 @@ # V3 setup-dotnet -Date: 2021-06-30 +Date: 2022-08-25 Status: Proposed # Context From 2d9def70671f9768f130a1750b8e76d056968671 Mon Sep 17 00:00:00 2001 From: Vladimir Safonkin Date: Sun, 11 Sep 2022 13:42:07 +0200 Subject: [PATCH 4/6] Rework --- docs/adrs/v3-setup-dotnet.md | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md index fd0d556e6..325131aaf 100644 --- a/docs/adrs/v3-setup-dotnet.md +++ b/docs/adrs/v3-setup-dotnet.md @@ -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 \ No newline at end of file +- Customers will be able to use pre-installed .NET versions with setup-dotnet action on Windows and Ubuntu \ No newline at end of file From 52c3199a78d0d1eb612d2a2afdcc48f89b6f9874 Mon Sep 17 00:00:00 2001 From: Ivan <98037481+IvanZosimov@users.noreply.github.com> Date: Tue, 13 Sep 2022 12:41:55 +0200 Subject: [PATCH 5/6] ADR change (#1) * Update ADR proposal ADR proposal was updated in order to reflect cahnges that will be done more thoroughly. * Fix formatting --- docs/adrs/v3-setup-dotnet.md | 38 +++++++++++++++++++++++++----------- 1 file changed, 27 insertions(+), 11 deletions(-) diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md index 325131aaf..b950a7705 100644 --- a/docs/adrs/v3-setup-dotnet.md +++ b/docs/adrs/v3-setup-dotnet.md @@ -1,4 +1,4 @@ -# V3 setup-dotnet +# v3 setup-dotnet Date: 2022-08-25 Status: Proposed @@ -7,31 +7,47 @@ Status: Proposed - GitHub-hosted Ubuntu and Windows runners have .NET versions pre-installed in system directories - Ubuntu:`/usr/share/dotnet` - Windows:`C:\Program Files\dotnet` -- V1 version of Action installs .NET to user's directory +- V1 version of Action installs .NET to the user's directory - Ubuntu:`/home/runner/.dotnet` - Windows: `C:\Users\runneradmin\AppData\Local\Microsoft\dotnet` -- It means that action always download and install .NET version even if it is pre-installed. Also after using the action all pre-installed .NET versions are unavailable because `DOTNET_ROOT` is overriden to user's directory. -The behavior is different for macOS runners because pre-installation directory matches the one that is used by action. It means action can use pre-installed versions if they exist, which speeds up customer's workflow. +- It means that action always downloads and installs .NET version even if it is pre-installed. Also after using the action all pre-installed .NET versions are unavailable because `DOTNET_ROOT` is overridden to the user's directory. +The behavior is different for macOS runners because the pre-installation directory matches the one that is used by action. It means action can use pre-installed versions if they exist, which speeds up the customer's workflow. -- The different behavior of the setup task on Ubuntu, Windows and MacOS runners is unclear and confusing for customers. +- The different behavior of the setup task on Ubuntu, Windows and macOS runners is unclear and confusing for customers. - .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 the 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 +- Simplify and in some cases fully get rid of logic for resolving wildcard versions 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. If SDK is in the prerelease phase, the latest prerelease version (preview or rc) will be installed. + +Inputs with wildcards in the patch tag (`5.0.x` or `5.0.*`) can be handled by passing major and minor versions to the installer script directly as a `channel` parameter. This parameter supports two-part version in `X.Y` format as input value ([see installer scripts documentation](https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script)). + +Inputs with wildcards in the minor tag (`3.x` or `3.*`) can be handled like that: +1. The request is sent to MS dist and the `releases.json` file is got +2. The action gets the latest possible channel version out of retrieved `releases.json` that satisfies input major tag (e.g. for `3.x` nowadays it's `3.1`) +3. Retrieved channel version is passed to installer script directly as `channel` parameter. + +> **Note:** Using the `channel` parameter of the MS .NET installer scripts will allow us to use the `quality` parameter as well. This functionality is also asked for by our customers. + # 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. +- The presence of pre-installed .NET versions that are higher than the version that the users specify in the setup task can be breaking for some customers, who expect only one installed .NET version on the runner after using the setup task. If a user doesn't have .NET version specified in project file, the `dotnet` will use the latest installed version instead of provided in the setup task. > **Note:** It is the biggest deal in this ADR. -Previously, when a user would specify a .NET version, this exact version was used by `dotnet` command by default (because it was installed in a separate folder and there were no other.NET versions in that folder) -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. -To avoid breaking customers, we will need to release a new major task version (V3). +Previously, when a user would specify a .NET version, this exact version was used by the `dotnet` command by default (because it was installed in a separate folder and there were no other.NET versions in that folder) +In the proposal, the specified version will be installed on the machine but the latest version will be used by the `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 customer's workflows could be broken because they already rely on current behavior. + +To avoid breaking customers, we will need to release a new major task version (v3). # v3-preview -There will be a v3-preview branch that will be created for development and testing. Any changes will first be merged into v3-preview branch. After a period of testing & verification, the v3-preview branch will be merged into the main branch and a v3 tag will be created. Any GitHub public documentation and starter workflows that mention setup-dotnet will then be updated to use v3 instead of v2: +There will be a v3-preview branch that will be created for development and testing. Any changes will first be merged into the v3-preview branch. After a period of testing & verification, the v3-preview branch will be merged into the main branch and a v3 tag will be created. Any GitHub public documentation and starter workflows that mention setup-dotnet will then be updated to use v3 instead of v2: - [README.md](https://github.com/actions/setup-dotnet/blob/main/README.md) - [action.yml](https://github.com/actions/setup-dotnet/blob/main/action.yml) - [GitHub docs](https://docs.github.com/en/actions/guides/building-and-testing-net#using-a-specific-net-version) From 95e7de77d131672c2cfcc56315caa7ae236b9498 Mon Sep 17 00:00:00 2001 From: Vladimir Safonkin Date: Tue, 13 Sep 2022 16:19:35 +0200 Subject: [PATCH 6/6] Set status accepted --- docs/adrs/v3-setup-dotnet.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/adrs/v3-setup-dotnet.md b/docs/adrs/v3-setup-dotnet.md index b950a7705..30e849512 100644 --- a/docs/adrs/v3-setup-dotnet.md +++ b/docs/adrs/v3-setup-dotnet.md @@ -1,7 +1,7 @@ # v3 setup-dotnet Date: 2022-08-25 -Status: Proposed +Status: Accepted # Context - GitHub-hosted Ubuntu and Windows runners have .NET versions pre-installed in system directories