[release/7.0] Update dependencies from dotnet/arcade

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/arcade

• Subscription: 28ee1be7-14cf-4fcb-6f5f-08da7ef6374d
• Build: 20220823.1
• Date Produced: August 23, 2022 3:56:41 PM UTC
• Commit: e2fcd61c25c61c6ad0c2a649c8f257077fb1fd88
• Branch: refs/heads/main

• Updates:
  • Microsoft.DotNet.Arcade.Sdk: from 7.0.0-beta.22418.4 to 7.0.0-beta.22423.1
  • Microsoft.DotNet.Build.Tasks.Templating: from 7.0.0-beta.22418.4 to 7.0.0-beta.22423.1
  • Microsoft.DotNet.Helix.Sdk: from 7.0.0-beta.22418.4 to 7.0.0-beta.22423.1

[ghost]

Auto-approving dependency update.

[dougbu]

Weird❕ I closed a previous PR and triggered the subscription again. However, the 20220819.1 build is far from the latest in Arcade. Later builds have also been validated.

We need #20220822.4 or later. (That shows as validated in the #20220822.4 build of dotnet-arcade-validation-official. The Maestro web site indicates Maestro++ is behind.

What's going on @mmitche @riarenas @jonfortescue❔

[dougbu]

Requesting changes 'til this gets a new enough Arcade

[riarenas]

https://dev.azure.com/dnceng/internal/_build/results?buildId=1960080&view=logs&j=4a10048b-3e0d-569f-b7f7-7fdf7fce1796&t=6fdd765e-f20e-5d31-a15a-fe4491eb552a&l=32 shows that we didn't move the build from the validation channel to the 'latest' channel due to the main build of installer being broken.

As a reminder, we don't automatically promote builds if some of the bigger repos have failing builds, due to asks to not introduce more variables to a build break.

[dougbu]

I am very surprised a supposedly successful (yes, succeeded w/ issues) validation failed to promote the incoming build. This makes everything murkier than it should be. That failure should have failed the build and been dealt w/ days ago. Now that you're seeing the failure, any idea how to get installer building again❔ For example is it just new nullability issues due to increased annotations in the newer xUnit❔

[mmitche]

I am very surprised a supposedly successful (yes, succeeded w/ issues) validation failed to promote the incoming build. This makes everything murkier than it should be. That failure should have failed the build and been dealt w/ days ago. Now that you're seeing the failure, any idea how to get installer building again❔ For example is it just new nullability issues due to increased annotations in the newer xUnit❔

This is a policy decision. We decide to not "add to the noise" of a repo that is already broken. So the validation build did not break in this case. It looked at the installer, aspnetcore, and runtime builds, one or more of which were failing, and decided not to promote arcade. There is no resolution in arcade-validation.

[dougbu]

There is no resolution in arcade-validation.

I agree w/ this but don't see how to resolve the issue in general. Problems have been continuous since the …19.1 build and I don't know even where the actual installer errors are hidden.

[mmitche]

There is no resolution in arcade-validation.

I agree w/ this but don't see how to resolve the issue in general. Problems have been continuous since the …19.1 build and I don't know even where the actual installer errors are hidden.

DownloadFile, probably: https://dev.azure.com/dnceng/internal/_build/results?buildId=1960569&view=logs&j=714e733b-840b-550d-6a88-8688f5d4d794&t=13efd35e-5bd2-5d7c-a65d-2e64bb81842f&l=134

validation isn't actually testing the proposed arcade updated against installer. It's just checking the status of the main branch of installer. https://dev.azure.com/dnceng/internal/_build?definitionId=286&_a=summary&branchFilter=152838%2C152838%2C152838%2C152838

[mmitche]

If we believe that arcade contains the fix for such issues (which it may), then we manually promote the build.

[dougbu]

If we believe that arcade contains the fix for such issues (which it may), then we manually promote the build.

I remember a FR conversation about DownloadFile somewhere. @rainersigwald @MattGal was it mostly betwixt the two of you❔ And was the upshot an Arcade fix over the last couple of days❔

[MattGal]

If we believe that arcade contains the fix for such issues (which it may), then we manually promote the build.

I remember a FR conversation about DownloadFile somewhere. @rainersigwald @MattGal was it mostly betwixt the two of you❔ And was the upshot an Arcade fix over the last couple of days❔

After realizing the built-in-to-MSBuild one didn't have it, I added TaskCanceledException as a reason we retry in dotnet/arcade#10542, but it doesn't seem like this sort of problem could reproduce repeatably without something else fishy going on, and it didn't reproduce in the linked pipeline. As such, it doesn't seem worth trying to promote it faster than the default speed, but I'm happy to help do so if there's a reason to.

[dougbu]

it doesn't seem worth trying to promote it faster than the default speed, but I'm happy to help do so if there's a reason to

My reasons were the loc fix (dotnet/arcade@f8733e0) needed to ensure loc PRs in aspnetcore / main don't continue to try updating files we don't care about and the xUnit update (dotnet/arcade@3fd7922) needed to ensure we don't have to deal w/ additional nullability issues in other repos (besides efcore) that get the xUnit version from Arcade. The first problem is causing more work for the loc team and the second means the workarounds in our 7.0.0 stabilization exercise are piling up.

[riarenas]

The latest run promoted the build: https://dev.azure.com/dnceng/internal/_build/results?buildId=1961706&view=results

[dougbu]

Whahoo❕ Should I trigger this sub immediately or wait 'til after lunch❔

[dougbu]

Actually, tried triggering just in case Maestro++ is ready to bring the latest here (didn't check the site)

[dougbu]

@maumar FYI it appears my test fix was needed here (same problems as w/ the internal 7.0.0-test branch). Guess the infra difference was actually about xUnit (which got a bump in the default version from Arcade just in the last day or so).