Fixes for internal runtime usage in build and PRs #35133
Conversation
- Don't conditionalize queue adds based on use of open queues. In eng/targets/Helix.targets, these are replaced with the non-open versions automatically - Don't use default error detection for the repo tasks build in source build, as this may pick up the error messages from the first attempts to install an internal runtime from a public location (it later succeeds using the private location.)
ghost
added
the
area-infrastructure
|
What do we expect to happen to this build queue? It's intent is to only run |
There is replacement logic in the repo that will replace '.Open' with the empty string when running on the internal project, where the .Open queues are not available. In public, the .Open queues are only available, and nothing changes. |
|
We don't want all of those jobs running on that internal queue, there's a public queue that runs them separately. Is there another internal queue where you're trying to enable these jobs? Do we need a different mechanic to disable these for the existing internal queue? |
This is for internal PRs only, not for enabling on official builds or whatnot. Right now no Helix tests are running on internal PRs. The intention is to mirror the public PRs in this case. |
|
But as a side-effect, they'll all start running on https://dev.azure.com/dnceng/internal/_build?definitionId=928, right? We'd want a way to suppress that. |
Good point. I'll look into getting that fixed. |
mmitche
force-pushed
the
source-build-aspnet-fixes
branch
from
0c8a956
to
e89ed05
Compare
|
@Tratcher Fixed this up. The previous logic on queue additions is a bit hard to follow (since the ci.yml queues ended up getting used for the helix-matrix and quarantine cases). I fixed it up by making the first block specific to PRs only and duplicating those 3 queues into the daily blocks in the right places. If this queue matrix ever gets more complicated it probably deserves a rework so that it's not a mishmash of conditionals. In these cases I tend to favor using some kind of enumeration identifier for each distinct scenario and then using the |
|
Thanks @mmitche, sounds good to me. I've pinged Hao for a fresh review of the implementation. |
Co-authored-by: Doug Bunting <6431421 [email protected]>
Co-authored-by: Doug Bunting <6431421 [email protected]>
Co-authored-by: Doug Bunting <6431421 [email protected]>
In eng/targets/Helix.targets, these are replaced with the non-open versions automatically
pick up the error messages from the first attempts to install an internal runtime from a public location (it later succeeds using the private location.)