Skip to content

[automated] Merge branch 'release/8.0' => 'release/8.0-staging'#129440

Open
github-actions[bot] wants to merge 5 commits into
release/8.0-stagingfrom
merge/release/8.0-to-release/8.0-staging
Open

[automated] Merge branch 'release/8.0' => 'release/8.0-staging'#129440
github-actions[bot] wants to merge 5 commits into
release/8.0-stagingfrom
merge/release/8.0-to-release/8.0-staging

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

I detected changes in the release/8.0 branch which have not been merged yet to release/8.0-staging. I'm a robot and am configured to help you automatically keep release/8.0-staging up to date, so I've opened this PR.

This PR merges commits made on release/8.0 by the following committers:

  • svick
  • steveisok

Instructions for merging from UI

This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.

merge button instructions

If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.

Instructions for merging via command line

Run these commands to merge this pull request from the command line.

git fetch
git checkout release/8.0
git pull --ff-only
git checkout release/8.0-staging
git pull --ff-only
git merge --no-ff release/8.0

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet/runtime HEAD:merge/release/8.0-to-release/8.0-staging
or if you are using SSH
git push git@github.com:dotnet/runtime HEAD:merge/release/8.0-to-release/8.0-staging

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

Instructions for updating this pull request

Contributors to this repo have permission update this pull request by pushing to the branch 'merge/release/8.0-to-release/8.0-staging'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.

git fetch
git checkout -b merge/release/8.0-to-release/8.0-staging origin/release/8.0-staging
git pull https://github.com/dotnet/runtime merge/release/8.0-to-release/8.0-staging
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/runtime HEAD:merge/release/8.0-to-release/8.0-staging
or if you are using SSH
git fetch
git checkout -b merge/release/8.0-to-release/8.0-staging origin/release/8.0-staging
git pull git@github.com:dotnet/runtime merge/release/8.0-to-release/8.0-staging
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet/runtime HEAD:merge/release/8.0-to-release/8.0-staging

Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.

steveisok and others added 3 commits June 10, 2026 13:45
Merges `release/8.0-staging` into `release/8.0`.

This is a routine forward-merge of the staging branch into the release
branch. The merge was performed with no conflicts.

> [!NOTE]
> This pull request was generated with the assistance of GitHub Copilot.
@github-actions github-actions Bot added the area-codeflow for labeling automated codeflow label Jun 15, 2026
…129049)

> [!NOTE]
> This pull request was authored with the assistance of GitHub Copilot.

## Problem

Several scheduled outerloop pipelines (the `outerloop.yml` family:
`runtime-libraries-coreclr outerloop` and its `-windows`/`-linux`/`-osx`
variants) use an `always: false` scheduled trigger. With `always:
false`, AzDO only starts a new scheduled run if the source changed
**since the last _successful_ scheduled run**.

Because the repo has many flaky outerloop tests, the Helix test work
items virtually always have at least one failure, which fails the "Send
to Helix" step and therefore the whole build. The build never reaches a
`succeeded` state, so AzDO re-queues **the same, unchanged commit** day
after day, submitting more and more Helix work for no benefit.
(Empirically confirmed: a single commit was re-run and failed for 19
consecutive days; once a sibling definition produced a genuinely
successful run, the same-SHA re-queue stopped.)

## Why `continueOnError` is not enough

`continueOnError: true` only downgrades the build to
`partiallySucceeded`, which AzDO's `always: false` scheduler still does
**not** treat as successful — so the same commit keeps getting
re-queued. The Helix step must end **fully successful** (exit 0).

## Fix

Make the "Send to Helix" step actually succeed on scheduled runs by
disabling the two Arcade `Microsoft.DotNet.Helix.Sdk` properties that
fail the build (both default to `true`):

- **`FailOnWorkItemFailure`** — `CheckHelixJobStatus` errors when a work
item exits non-zero.
- **`FailOnTestFailure`** — `CheckAzurePipelinesTestResults` errors when
any published test failed.

Setting both to `false` lets the msbuild step exit 0, producing a fully
`succeeded` build. Failed tests are still published and visible in the
test results tab; AzDO does not auto-degrade a build to
`partiallySucceeded` just because a published test run contains failures
— only a failing task would.

### Changes

- **`eng/pipelines/libraries/helix.yml`**: Added a `failOnTestFailures`
parameter (default `true`, preserving today's behavior) wired to
`/p:FailOnWorkItemFailure` and `/p:FailOnTestFailure` on the Send to
Helix msbuild invocation.
- **`eng/pipelines/libraries/outerloop.yml`**: Passes
`failOnTestFailures: false` **only on scheduled runs** (`Build.Reason ==
'Schedule'`) for all three matrix legs (Release, Debug, NET48).

## Behavior preservation

The new parameter defaults to `true`, so all other `helix.yml` callers
are unaffected (none set `WaitForWorkItemCompletion` or these properties
on this path, so they already resolve to `true`). Only scheduled
outerloop runs change behavior. PR / rolling / manual outerloop runs
continue to fail on Helix failures exactly as before. Build/compile
breaks still fail scheduled runs (this only affects the Helix step).

## Tradeoff

On scheduled runs, `FailOnWorkItemFailure=false` also masks work-item
crashes/timeouts/infra failures, not just test-assertion failures. This
is an accepted tradeoff for the goal of stopping the wasteful daily
re-queue of unchanged commits; results remain visible in the Helix/test
reporting.

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…9629)

## Problem

PR #129049 made scheduled outerloop builds succeed when only Helix tests
fail, by setting `FailOnWorkItemFailure`/`FailOnTestFailure` to `false`
on scheduled runs (via the `failOnTestFailures: false` parameter). This
stopped AzDO's `always: false` scheduler from re-queueing the same
commit day after day.

The side effect: failed Helix work items became **completely invisible**
in the Azure DevOps timeline. The `Send to Helix` step is fully green,
so there is no signal that work items failed (even though, for flaky
outerloop, they almost always do).

## Fix

Surface failed work items as **warnings** instead of silently dropping
them. Warnings keep the failures visible in the timeline but do **not**
degrade the build below `succeeded` (so the `always: false` re-queue fix
from #129049 is preserved).

- **`src/libraries/sendtohelixhelp.proj`**: new
`WarnOnHelixWorkItemFailure` target (`AfterTargets=CheckHelixJobStatus`)
that emits a `<Warning>` for each failed `@(CompletedWorkItem)` when
`WarnOnHelixTestFailure=true`. This mirrors what the Arcade SDK's
`CheckHelixJobStatus` would have *errored* on, but as a warning.
- **`eng/pipelines/libraries/helix.yml`**: new `warnOnTestFailures`
parameter (default `false`) wired to `/p:WarnOnHelixTestFailure`.
- **`eng/pipelines/libraries/outerloop.yml`**: scheduled runs now set
`warnOnTestFailures: true` alongside `failOnTestFailures: false` on all
three legs.

No warn-as-error change was needed: the `Send to Helix` step already
runs with warnaserror disabled (`_warnAsErrorParamHelixOverride`), so
these warnings are not promoted back into build-failing errors.

## Validation

Ran the `runtime-libraries-coreclr outerloop` pipeline (dnceng-public
def 125, [build
1472840](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1472840))
with a temporary Manual gate. Multiple CoreCLR_Release legs completed
**succeeded** with failed work items surfaced as warnings and **zero
errors**, e.g.:

```
src/libraries/sendtohelixhelp.proj(364,5): warning : Work item System.Runtime.Numerics.Tests in job 2e01f1b1-... has failed. Failure log: https://helix.dot.net/api/.../console
```

Legs whose work items all passed produced no such warning, as expected.

> [!NOTE]
> This pull request was authored with the assistance of GitHub Copilot.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-codeflow for labeling automated codeflow

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants