Bump globals.yml .NET SDK version from 3.1.405 to 6.x + assorted changes
#4916
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
konrad-jamrozik
changed the title
konrad-jamrozik
added
the
Central-EngSys
weshaggard
reviewed
Dec 8, 2022
| @@ -1,6 +1,6 @@ | |||
| variables: | |||
| OfficialBuildId: $(Build.BuildNumber) | |||
| skipComponentGovernanceDetection: true | |||
| DotNetCoreVersion: '3.1.405' | |||
| DotNetCoreVersion: '6.0.403' | |||
There was a problem hiding this comment.
We are also going to need to update our target frameworks in the various projects.
There was a problem hiding this comment.
We have also talked about moving this version into https://github.com/Azure/azure-sdk-tools/blob/main/global.json similar to what azure-sdk-for-net repo does.
There was a problem hiding this comment.
We are also going to need to update our target frameworks in the various projects.
I found more issues related to this caused by SDKs going out of support. Please see #4934 and #4935.
However, once these problems are solved, I don't think that TargetFramework has to exactly match the SDK used, as long as the targeted framework is not newer than the SDK and is not obsolete. Which admittedly is a bit moot point now, because everything before net6.0 is obsolete (-:
We have also talked about moving this version into https://github.com/Azure/azure-sdk-tools/blob/main/global.json similar to what azure-sdk-for-net repo does.
How about I do the migration to global.json in a separate, follow-up PR?
- Update 12/20/2022: I filed Migrate to
global.jsonfor .NET usage in our templates #5009
Also, I think this PR is no longer required to unblock PR #4915 per my comment there, so I suggest we go ahead with merging #4915 to mitigate #4888, and then work on more broad fix proposed by this PR.
|
/check-enforcer override |
konrad-jamrozik
force-pushed
the
users/kojamroz/iss_4880_archetype_net60
branch
from
f013412 to
1dac5d0
Compare
ghost
pushed a commit
that referenced
this pull request
Dec 12, 2022
… to use Ubuntu 20.04 (#4930) This PR, in tandem with PRs #4915 and #4916, addresses #4888. This PR subsumes the abandoned PR of #4911. Specifically, this PR ensures that `prepare-pipelines.yml` is configured to use specific `pool`, set to use Ubuntu 20.04: ``` pool: name: azsdk-pool-mms-ubuntu-2004-general vmImage: MMSUbuntu20.04 ``` Without the [pool](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/pool?view=azure-pipelines) definition pointing to Ubuntu 20.04, the steps within the file used an implicit default, which resolves to `ubuntu-latest`. This caused breakage as explained in #4888. Setting the pool to Ubuntu 20.04 will allow us to: - Immediately unblock the language repos `prepare-pipelines.yml` pipelines [1], as Ubuntu 20.04 has the .NET Core version used by it [2]; - Allow us to migrate our tooling to .NET 6 as both Ubuntu 20.04 and `ubuntu-latest`, which is Ubuntu 22.04 [3], have .NET on them [4]. This step is accomplished by PRs #4916 and #4915; - Allow us to migrate to Ubuntu 22.04 once we migrate to .NET 6. ## Technical considerations of the changes - The current `prepare-pipelines.yml` has only [steps](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/steps?view=azure-pipelines) definition, which does not support `pool` definition. One needs to wrap the steps in [job](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/jobs-job?view=azure-pipelines) definition to support `pool` [5]. - Because the `.yml` file is located in `eng/common/pipelines/templates/steps/` directory (note the `steps`), we cannot wrap the steps in job and leave it there; the introduction of `job` necessitates introducing the changes in `eng/common/pipelines/templates/jobs/` directory instead (note the `jobs`), which is done in this PR. - Because this PR introduces a new file, once this PR is merged, the language-specific `prepare-pipelines.yml` language pipelines need to be rewired to point to the newly introduced file. This approach was proposed in #4911 (comment). - Language repos PRs doing the rewiring: Azure/azure-sdk-for-net#32999 ... more to come! ## Testing done I have confirmed the proposed modification to the `.yml` file will work [by modifying the existing `prepare-pipelines.yml` directly](Azure/azure-sdk-for-java@f8cef4c) to have exactly the same contents as the `/jobs/prepare-pipelines.yml` introduced in this PR, and observing the [relevant build succeeds on azure-sdk-for-java](https://dev.azure.com/azure-sdk/internal/_build/results?buildId=2044120&view=logs&j=7f42699e-eeb0-56c8-40c2-c88ae4093e4f&t=a02502cb-238e-5603-14ee-8bb7bd07f0c6):  while it failed before this change:  # Footnotes [1] for example, [internal / java / prepare-pipelines](https://dev.azure.com/azure-sdk/internal/_build?definitionId=2158&_a=summary) pipeline, or [internal / net / prepare-pipelines](https://dev.azure.com/azure-sdk/internal/_build?definitionId=2179) pipeline. [2] as evidenced by the [Ubuntu 20.04 image software page](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2004-Readme.md#net-core-sdk), it has .NET Core 3.1. The pool definition value points to a 1ES hosted image which has the software listed on that page, as explained by this comment: #4888 (comment). [3] See this comment: #4888 (comment). [4] as evidenced by the [Ubuntu 22.04 image software page](https://github.com/actions/runner-images/blob/main/images/linux/Ubuntu2204-Readme.md#net-core-sdk). [5] Observe that on [pool definition](https://learn.microsoft.com/en-us/azure/devops/pipelines/yaml-schema/pool?view=azure-pipelines) YAML reference page, we can read: > Properties that use this definition: pipeline.pool, stages.stage.pool, jobs.job.pool, jobs.deployment.pool. i.e. `steps.pool` is not listed.
konrad-jamrozik
force-pushed
the
users/kojamroz/iss_4880_archetype_net60
branch
2 times, most recently
from
aa517b8 to
8128edd
Compare
konrad-jamrozik
changed the title
konrad-jamrozik
force-pushed
the
users/kojamroz/iss_4880_archetype_net60
branch
from
3097908 to
9ca067f
Compare
|
@weshaggard @benbp this PR is ready for review for approval. Thx! :) |
added 5 commits
December 14, 2022 14:15
…ol-azure-function.yml
…entity-resolution build
weshaggard
reviewed
Dec 15, 2022
weshaggard
approved these changes
Dec 15, 2022
weshaggard
reviewed
Dec 15, 2022
This was referenced Dec 17, 2022
konrad-jamrozik
changed the title
3.1.405 to 6.x + assorted changes
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Updating .NET SDK version from
3.1.405to6.xfor our pipelines because:.NET Core 3.1support is ending on December 13, 2022, hence we want to move to a supported SDK. See also Some of our internal pipelines fail to build due to using out-of-support .NET SDKs #4934..NET Core 3.1support is ending, it got removed from latest Ubuntu images, and in some places we we didn't pin the Ubuntu image, thus resulting in us using the latest image, thus leading to issues, like The template for prepare-pipelines is broken by the move to ubuntu-22.04 #4888.PipelineGeneratorto .NET 6, which we do in PR Update PipelineGenerator target framework fromnetcoreapp3.1tonet6.0#4915. But for the PR Update PipelineGenerator target framework fromnetcoreapp3.1tonet6.0#4915 to successfully build, this PR needs to be merged first, as explained in Update PipelineGenerator target framework fromnetcoreapp3.1tonet6.0#4915 (comment).GitHubIssuesTargetFrameworkas it wasn't included in update made in PR Set .NET used by our tools tonet6.0+ minor updates to .sln files #4937.I chose
6.xbecause this is the version installed on the image we use, as explained in #4915 (comment).Note: Alternatively, I could have used
6.0.403, because it is a string that is present inreleases / sdk / versionin the releases.json, as explained in UseDotNet@2 task doc. For more, see #4915 (comment).Changes made
globals.yml, which is picked by ourarchetypefiles;archetype-sdk-tool-azure-function.ymlto usenet6.xand does few other assorted changes.GitHubIssues, updatedMicrosoft.NET.Sdk.Functionsfrom3.0.9to4.1.3, as the old version depended on obsolete .NET SDK version.archetype-sdk-tool-dotnet.yml, ensured the directory from which packages are to be published always exists, even if it wasn't created by previous steps because they didn't create any packages. This is the case e.g. foridentity-resolution - ciwhich caused it to fail after the update of .NET version. This appears to be a behavior change introduced in .NET 6 or earlier. Unfortunately, there is no "directory exists" expression: the doc doesn't mention it, and relevant issues or feature requests only propose workarounds: azure-devops-docs #1877 and developer community 366095.Note I did not update
CheckEnforcerandWebhookRouteras they are scheduled for deletion per #4937 (review). PRs doing that: