Split Helix into separate AzDO jobs per queue, enable verbose xunit, configurable timeout#38003
Conversation
…es, enable verbose xunit, set unit test timeout to 10 minutes Co-authored-by: AndriySvyryd <6539701+AndriySvyryd@users.noreply.github.com> Agent-Logs-Url: https://github.com/dotnet/efcore/sessions/5ee77dab-a54a-40a4-b850-1708e6cb6637
…move System.TeamProject condition, expiryInHours=3 Co-authored-by: AndriySvyryd <6539701+AndriySvyryd@users.noreply.github.com> Agent-Logs-Url: https://github.com/dotnet/efcore/sessions/343ccd50-5c61-480e-9b34-15064570b02c
There was a problem hiding this comment.
Pull request overview
This PR refactors EF Core’s CI Helix submission to run each Helix queue as an independent Azure DevOps job, improving retryability and isolating queue-specific failures. It also increases xUnit verbosity and makes Helix work item timeouts configurable.
Changes:
- Split the single Helix job into per-queue Helix jobs in both public and internal Azure Pipelines.
- Enable verbose xUnit output via
XUnitArgumentsineng/helix.proj. - Make Helix work item timeout configurable via
XUnitWorkItemTimeout(defaulting to 2 hours) and adjust SAS token acquisition in the internal pipeline.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
eng/helix.proj |
Enables verbose xUnit logging and supports configurable Helix work item timeout. |
azure-pipelines-public.yml |
Splits Helix submission into per-queue jobs for public CI. |
azure-pipelines-internal-tests.yml |
Splits Helix submission into per-queue jobs for internal CI and updates delegation SAS handling. |
Agent-Logs-Url: https://github.com/dotnet/efcore/sessions/91bcbf34-d415-4720-b45f-18c42673a0d4 Co-authored-by: AndriySvyryd <6539701+AndriySvyryd@users.noreply.github.com>
…s (already set in helix.proj) Agent-Logs-Url: https://github.com/dotnet/efcore/sessions/1360f071-35e2-44ac-82cf-75cb3d8737bb Co-authored-by: AndriySvyryd <6539701+AndriySvyryd@users.noreply.github.com>
| COMPlus_EnableWriteXorExecute: 0 | ||
| DotNetBuildsInternalReadSasToken: $(dotnetbuilds-internal-container-read-token) | ||
|
|
||
| - job: Helix_Ubuntu_Cosmos |
There was a problem hiding this comment.
Do we need a Cosmos-specific job? Especially now that we can test against the Linux-based emulator, shouldn't Cosmos testing just happen as part of all testing jobs, like SQLite?
There was a problem hiding this comment.
We can look at the run times once this is running and combine them later
There was a problem hiding this comment.
I meant this more in terms of simplicity, not of run times optimizations; like why would we have a separate job in Helix specifically for Cosmos and not for SQLite...
But no particular blocking from my side, am OK to merge as-is.
Each Helix queue now runs as its own AzDO job so individual queue failures can be retried without re-running everything.
Per-queue Helix jobs
Helixjob with 6 independent jobs in bothazure-pipelines-public.ymlandazure-pipelines-internal-tests.yml:Configurable timeout
XUnitWorkItemTimeoutineng/helix.projdefaults to02:00:00but can be overridden per job via/p:XUnitWorkItemTimeout=...Verbose xunit
<XUnitArguments>-verbose</XUnitArguments>ineng/helix.projEnvironment variable scoping
MSSQL_SA_PASSWORDis only set on Helix Ubuntu SQL Server jobs in pipeline YAMLCOMPlus_EnableWriteXorExecuteis handled entirely insideeng/helix.projviaPreCommandsfor OSX queues (removed from pipeline YAML)DotNetBuildsInternalReadSasTokenfrom public pipeline Helix jobs (variable is never populated in that pipeline)Internal pipeline cleanup
System.TeamProjectcondition from delegation SAS steps (neverpublicin this pipeline)expiryInHoursto 3 for all delegation SAS steps🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.