Update public pool names

[alexperovich]

This change is required for builds to continue working in the new org, dev.azure.com/dnceng-public.

[ghost]

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

Issue Details

---

This change is required for builds to continue working in the new org, dev.azure.com/dnceng-public.

Author:	alexperovich
Assignees:	-
Labels:	area-Infrastructure-libraries
Milestone:	-

[ViktorHofer]

This one can be closed in favor of #74906 which flows automatically into release/7.0.

[carlossanlop]

This should've been merged. We aren't working on rc1 anymore. The release/7.0 branch is the one we are actively working on and is currently blocked until we merge the backport.

[ViktorHofer]

Must disagree here. The same PR was already merged into release/7.0-rc1 and as we still have the maestro flow enabled, we don't need this one.

[carlossanlop]

Right, but we already generated a coherent build out of RC1 so that branch is 'done'. Merging here, then waiting for the bot to flow it to release/7.0 was an unnecessary step, considering we are all now actively working in the release/7.0 branch.

[ViktorHofer]

Consider someone noticing a highly impactful bug in the runtime that impacts RC1 during validation. We would need to fix that and re-spin the builds. I think it was right for @alexperovich to target release/7.0-rc1 to make sure that in the worst case, this branch continues to be buildable. And as that PR already targeted release/7.0-rc1, there was no need to also target release/7.0.

Basically what I'm saying is that these three PRs could have just been one (which is why I closed the other ones):

• Update public pool names #74906
• Update public pool names #74907
• [automated] Merge branch 'release/7.0-rc1-publicPoolNames' => 'release/7.0' #74901

[carlossanlop]

Hmm ok, fair enough.

What is the recommended way to restart the CI on the backports that didn't get the CI of the newest commits triggered due to the system being down? /azp run runtime? Closing and reopening? Something else?

[ViktorHofer]

Closing and reopening probably otherwise you would need to azp run all pipelines that are enabled per PR.

[carlossanlop]

Thanks. But one of those two does not rebase with the base branch, right? I think the correct case here is to use closing and reopening, since we need the PRs to consume the server name changes.