Merge release/2.1.3xx-MSRC to release/2.1.3xx #9633
Conversation
Updated the CLI branding to 2.1.302
… into a separate variable
Fix alpine file ownership issues with newer docker Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image).
…for Microsoft.NETCore.App "2.1.0" or "2.1.1*"
* release/2.1.3xx: Disable NewProjectRestoresCorrectPackageVersion "console" test for now. Update the version for 'microsoft.netcore.app' to "2.1.1*" Pass "PB_AssetRootUrl" explictly on the MSBuild call; we are looking for Microsoft.NETCore.App "2.1.0" or "2.1.1*" Fix alpine file ownership issues with newer docker Upgrades to a newer docker version (18.03.1-ce) caused files created inside to be owned by root on alpine. It appears that the logic to set up the user in the container so that this doesn't happen was missing from alpine. While it's not clear why it worked before at all, the logic has been duplicated (tweaked for the alpine base image). Remove -upgrade suffix from installer inputs Ensure default aspnetcore metapackage versions doesn't jump when/if we ever get to version `2.1.10` Add retry when Directory.Move (#9313) Fix mismatch of dotnet-watch with package variable name Set package versions for bundled aspnet tools separately from the metapackage version Split the version of Microsoft.AspNetCore.DeveloperCertificates.XPlat into a separate variable Fixup myget feed for aspnetcore Upgrade to aspnetcore 2.1.1-rtm-30818 and react to file name change Set Default aspnetcore metapackage versions
* release/2.1.3xx: Updating the CLI stage0 to 2.1.300 and fixing some build failures. Update Microsoft.NETCore.App Package Version Formatting... Drop the LZMA archive for every build.
Merge from upstream release/2.1.3xx Note: this conflicted with several cherry-picked commits that were already present in release/2.1.3xx-MSRC.
* release/2.1.3xx: Update SDK/WebSDK dependencies to 2.1.1 Revert undesired changes Update coresetup, msbuild, nugetclient, roslyn to preview1-26216-03, 15.7.177, preview1.5116, beta6-62923-07, respectively Correct the 'Channel' and 'BranchName' to "release/2.1.3xx"
…1.3xx-MSRC Including in this merge: #9495 The "pack" command under 'buildCrossTargeting' for 'Microsoft.DotNet.MSBuildSdkResolver' now throws a "NU5104" warning/error because the SDK stage0 was changed to "2.1.300" [change was intended]. Impact: package failure for Linux-x64, Linux-arm, and Linux-arm64 #9491 The version of 'Microsoft.AspNetCore.Mvc' should be independent of 'Microsoft.AspNetCore.All' Impact: RazorApp test failure in all legs except for Linux-arm and Linux-arm64
…ps to be pinned as 2.1.1. Change the implicit asp.net core version for FDD apps to be pinned as 2.1.1.
- If this PR should not run tests please add text "skip[REMOVE_THIS]ci[REMOVE_THIS]please" (remove the marked text, no quotes). - Please add description for changes you are making. - If there is an issue related to this PR, please add the reference.
* release/2.1.3xx-MSRC: Updates asp.net versions to match prodcon Change the implicit asp.net core version for FDD apps to be pinned as 2.1.1. Update expected versions to 2.1.2 Disable NewProjectRestoresCorrectPackageVersion "console" test for now. Update the version for 'microsoft.netcore.app' to "2.1.1*" Pass "PB_AssetRootUrl" explictly on the MSBuild call; we are looking for Microsoft.NETCore.App "2.1.0" or "2.1.1*" Merged PR 126122: Fix alpine file ownership issues with newer docker Fix mismatch of dotnet-watch with package variable name Set package versions for bundled aspnet tools separately from the metapackage version Split the version of Microsoft.AspNetCore.DeveloperCertificates.XPlat into a separate variable Fixup myget feed for aspnetcore Upgrade to aspnetcore 2.1.1-rtm-30818 and react to file name change Updated Version.props
|
Investigating test failures. |
This also refactors the ASP.NET SDKs to have independent versions from the ASP.NET version.
|
@natemcmaster does the update to DependencyVersions.props work for you? |
|
Actually, no. The bundled templates should have been 2.1.2. These are supposed to stay aligned with AspNetCoreVersion |
|
@mmitche can we get the 2.1.2 assets published to myget or dotnetfeed? I'm guessing Peter picked the versions which were available publicly, but they are not quite right. |
|
Sigh. I both asked about the version number discrepancies and assumed since we were requested to merge and tag that all packages had been published (not possible to do otherwise). I'd like to examine why this keeps happening in our MSRC release process (specifically why we don't seem to publish all packages). I can revert the changes related to the bundled packages and update the tag. |
|
@peterhuene @natemcmaster What is missing that didn't get published to public feeds? |
|
My understanding from @natemcmaster is that the following packages should be 2.1.2:
The PR originally failed with the following: I assumed we didn't rev these package versions, so I kept them at 2.1.1, which was incorrect. |
|
Ahh, these are marked as non-shipping in the manifest, which is why they aren't on GitHub. @natemcmaster, they are just transport packages, and don't appear in the package graph. Okay, so in that case I'm going to put in temporary post-build steps and have the final bits published. |
|
Getting the versions right manually is tough, which is why I was recommending automation to read the prodcon build.xml output file to determine those versions. I still recommend using this to help keep things aligned. It's worked really well for us in aspnet. We even have dotnet-maaetro-bot making PRs to help our source code stay consistent with latest ProdCon builds. https://github.com/aspnet/Universe/blob/master/scripts/UpdateDependencies.ps1 |
|
@natemcmaster I agree, the issue is that all that automation today is chained together via the versions repo (which is public) and a large number msbuild targets, . Getting those updates is non-trivial for internal builds. |
|
I think part of our post-release private build -> public release steps should include the same mechanisms used to update myget, dotnet/versions, dotnetcli blobs, etc. We have to do that all manually today, and it’s a big pain.
|
|
Oh I agree, and I'm doing (most of that) now for the 2.1.2 bits. It's just a royal pain for a lot of reasons:
It's a minefield of gotchas and strung together automation and doesn't work well in these cases. We could go about improving it, but that's also taking away time from us ultimately building things to replace it. |
|
@mmitche Please let me know when everything is published as I'd like to update our release tag asap. |
No description provided.