[release/6.0-rc1] Update dependencies from dotnet/efcore

[dotnet-maestro]

This pull request updates the following dependencies

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

• Subscription: cfa6f77a-2257-465f-39aa-08d960f4ca81
• Build: 20210821.6
• Date Produced: 8/23/2021 5:07 PM
• Commit: e126ef2c755119f2125e835580f3a7b5ec6c4e08
• Branch: refs/heads/release/6.0-rc1

• Updates:
  • Microsoft.EntityFrameworkCore.Tools: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • dotnet-ef: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore.SqlServer: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore.InMemory: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore.Relational: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore.Sqlite: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6
  • Microsoft.EntityFrameworkCore.Design: from 6.0.0-rc.1.21420.45 to 6.0.0-rc.1.21421.6

[ghost]

Auto-approving dependency update.

[Pilchie]

@pranavkm @captainsafia - any ideas on the dotnet.aspnetcore-components failures?

[dougbu]

any ideas on the dotnet.aspnetcore-components failures?

That pipeline generally fails. Its pass rate was only about 13% last I looked. If we care about components tests, we either need to take the pain an run time in a required pipeline or start monitoring the pipeline in our dashboard.

Separately,

1. The fact Maestro is not auto-merging this is a bug in our darc configuration. We shouldn't require that pipeline to succeed given it's inability to provide useful results. Unfortunately, this will complicate our configuration and the policies @mmitche sets up as we branch.
2. The lack of aspnetcore-quarantined-pr runs for our release/6.0 and release/6.0-rc1 branches is a bug in the YAML for that pipeline.

[pranavkm]

The Components tests are known to be problematic in the CI and they do not currently block the build. In main, the results of these tests are entirely ignored and we rely on local testing to verify the sanity of things. We've some ideas about how to mitigate this before 6.0, but nothing concrete as yet.

tl;dr - feel free to ignore failing component tests for now. It's a known problem

[dougbu]

@pranavkm in the meantime, do you recommend we update (complicate) our darc subscription to ignore failures of the (poorly-named) dotnet.aspnetcore-components pipeline❔ One alternative would be to disable PR builds of that pipeline because we're getting enough failures in the rolling builds and little value from the additional builds.

[dougbu]

Actually, why do we have the pipeline at all when we "rely on local testing"❔

[pranavkm]

Actually, why do we have the pipeline at all when we "rely on local testing"❔

@SteveSandersonMS?

[SteveSandersonMS]

I suggested at #35484 (comment) that we disable it for now, but there was already a plan in progress at #35559 to make it just return green. It didn’t seem worthwhile to argue against that, especially given that continuing to run them might theoretically supply additional data that might help with future diagnosis of what’s going on in CI.

Personally I don’t strongly mind whether they run in CI or not, at least until I find a way to get CI to run them with the same reliability and consistency that I’m getting in an Azure VM.

[dougbu]

@SteveSandersonMS the main thing #35559 did was ignore reported test and build errors in the main build step. #35559 didn't work around pipeline timeouts and those are happening pretty frequently.

Unless I hear objections, I'll put up a PR to get rid of the PR builds of the pipeline later today. I also plan to rename the pipeline so it's just aspnetcore-components.

Are rolling builds of the components pipeline at all useful❔ I'd disable the pipeline if not. (Manual builds would remain possible when trying to fix the many problems w/ these tests.)

/cc @HaoK

[SteveSandersonMS]

As mentioned above, personally I’m fine with that build job not running at all. There’s too much angst and distraction surrounding it. It would be better to keep it out of other teams’ way until we have definite reliability solutions and/or a different strategy for running them.

[dougbu]

I disabled and renamed the pipeline. No PR necessary and no need to change the darc configuration.

[SteveSandersonMS]

[@dougbu] Manual builds would remain possible when trying to fix the many problems w/ these tests

@dougbu Could you let me know how I can run the pipeline manually? I'm working towards finding a way to run it reliably in CI. When I went through the AzDO UI and tried to run the pipeline, it said this:

Does it have to be re-enabled so it can be triggered manually?

[dougbu]

@SteveSandersonMS you should be able to trigger the pipeline manually in AzDO

[SteveSandersonMS]

@dougbu Sorry if I’m missing something obvious, but can you clarify how? I clicked the “Run” button but it gave me the error in the screenshot above.

[SteveSandersonMS]

It looks as if the way it's been disabled means that it's not possible to trigger the pipeline manually in AzDO. The Azure DevOps docs imply this at least:

Disabled pipelines prevent users from starting new runs. All triggers are also disabled while this setting is applied.

So instead, I'm creating a new pipeline that is enabled but (for now) has no triggers.

[dougbu]

Sorry for my misunderstandings. And, creating a new pipeline will absolutely work.