ci(notify): file/update ci-broken GitHub issue when internal AzDO build breaks on main/release/*#17920
Open
radical wants to merge 4 commits into
Open
ci(notify): file/update ci-broken GitHub issue when internal AzDO build breaks on main/release/*#17920radical wants to merge 4 commits into
radical wants to merge 4 commits into
Conversation
Contributor
|
🚀 Dogfood this PR with:
curl -fsSL https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 17920Or
iex "& { $(irm https://raw.githubusercontent.com/microsoft/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 17920" |
radical
force-pushed
the
radical/notify-internal-build-failure
branch
from
0e6133b to
fe60937
Compare
radical
changed the title
PowerShell helper that files / updates / closes a ci-broken GitHub issue on microsoft/aspire for a given branch. Two modes: - Failure: GETs open ci-broken issues, filters by a hidden HTML-comment marker (<!-- aspire-internal-build-broken:<branch> -->), and either creates a new issue (with a managed failures-table region in the body) or appends a row to the existing one and posts a follow-up @-mention comment. - Success: closes the matching open issue with a green-build comment. Drives the gh CLI throughout, authenticated via $env:GH_TOKEN that the caller sets after minting an aspire-repo-bot installation token. List uses the strongly-consistent /issues endpoint, not /search/issues, so near-simultaneous failures don't each file a duplicate; a post-create re-list catches the rare race past that window and closes ours as a duplicate of the older. Always exits 0. Warnings surface via task.logissue + task.complete result=SucceededWithIssues so a silent regression (bot loses permission, label deleted, gh API shape changes) goes yellow rather than green. -DryRun logs the would-be gh calls without mutating GitHub. In dry-run the script skips token mint entirely so the wrapper can validate pipeline plumbing without resolving aspire-repo-bot credentials. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ipeline Adds two stages to azure-pipelines.yml that gate on the upstream build_sign_native / build / prepare_installers stage results and run Notify-GitHubOnBuildResult.ps1 on 1es-ubuntu-2204: - notify_failure: fires when at least one upstream stage Failed. Composes a comma-separated -FailedStages list from dependencies.<stage>.result so the filed / updated issue body identifies which stage broke. - notify_success: fires when all three upstream stages Succeeded / SucceededWithIssues (prepare_installers may legitimately Skip on stable GA release builds). Closes the open ci-broken issue for the branch. Both stages mint the aspire-repo-bot installation token via Get-AspireBotInstallationToken.ps1 and export it as GH_TOKEN so the gh CLI invocations in the script authenticate as the bot. Adds _IsNotificationBranch in common-variables.yml — exact match on refs/heads/main (NOT startsWith, the pipeline trigger's `main*` wildcard would otherwise sweep in branches like main-something) plus startsWith refs/heads/release/. Excludes internal/release/* so internal branch names don't leak into the public tracker. Aspire-Release-Secrets variable group is imported at pipeline scope with the same non-PR + main/release/* gate, so manual feature-branch and PR runs don't pay the variable-group auth check at queue time. A notifyOnFailureDryRun queue-time parameter logs would-be gh calls without mutating GitHub; applies to both stages so a green-build dry-run can't accidentally close real open issues. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Adds docs/ci/internal-build-failure-notifications.md describing the contract (labels, marker syntax, failures-table region, dedupe behavior, dry-run, manual cleanup) and pointer from eng/pipelines/README.md so anyone reading the pipeline docs lands on the notification system. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
radical
force-pushed
the
radical/notify-internal-build-failure
branch
from
b3883d4 to
7870f74
Compare
radical
added
the
area-engineering-systems
Contributor
There was a problem hiding this comment.
Pull request overview
Adds automated public GitHub issue visibility for internal AzDO build breaks on main and release/*, so internal failures don’t remain unnoticed without someone manually checking AzDO.
Changes:
- Introduces a PowerShell notifier that files/updates a branch-deduped
ci-brokenissue on failures and closes it on the next green build. - Adds
notify_failure/notify_successstages to the internal pipeline, plus a queue-time dry-run parameter and branch gating. - Documents the notification contract and links it from pipeline docs.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
| eng/pipelines/scripts/Notify-GitHubOnBuildResult.ps1 | New notifier script that uses gh + an installation token to create/update/close ci-broken issues per branch. |
| eng/pipelines/README.md | Adds a short pointer describing the internal build-result notification behavior and links to full docs. |
| eng/pipelines/common-variables.yml | Adds _IsNotificationBranch to gate notifications to main/release/* (excluding internal/release/*). |
| eng/pipelines/azure-pipelines.yml | Adds dry-run parameter, imports secrets conditionally, and adds notify_failure/notify_success stages. |
| docs/ci/internal-build-failure-notifications.md | New contract documentation for behavior, dedupe strategy, and operational expectations. |
- Notify-GitHubOnBuildResult.ps1: register the GitHub App installation token via `##vso[task.setsecret]` instead of `##vso[task.setvariable ...;issecret=true]`. The only purpose was log masking, but task.setvariable also persists the value as a job-scoped variable that other tasks could accidentally reference via $(__notifyGhToken). task.setsecret gives us the masking without the persistence. - azure-pipelines.yml + docs: dry-run mode logs the `gh` CLI commands it would run, not GitHub REST calls. Fix the parameter displayName, the parameter comment, and the corresponding docs paragraph. - docs: Azure Pipelines stage results use `Skipped`, not `Skip` (the YAML stage condition correctly checks for 'Skipped'). Fix the prose. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Internal AzDO build failures on
mainandrelease/*had no automated visibility on the public tracker — a broken build could sit unnoticed until someone happened to look at the AzDO build list.What it does
On every non-PR build of
mainorrelease/*:ci-brokenissue onmicrosoft/aspire, titledInternal build broken on <branch>, assigned to @joperezr + @radical. The body carries a managed failures table that grows a row per subsequent failure on the same branch (build link, commit, failed stages). A follow-up comment fires on each failure so @-mentions notify.ci-brokenissue for that branch with a green-build comment.One open issue per branch, deduplicated by a hidden HTML-comment marker in the body. Full contract (labels, marker syntax, dedupe behavior, dry-run, manual cleanup) in
docs/ci/internal-build-failure-notifications.md.How
Notify-GitHubOnBuildResult.ps1invoked from two new pipeline stages (notify_failure,notify_success), authenticated via anaspire-repo-botGitHub App installation token, driving theghCLI. Always exits 0 — a flaky notification path must never red an otherwise-correct build.A
notifyOnFailureDryRunqueue-time parameter logs the would-beghcalls without mutating GitHub.Validated on AzDO
-FailedStageson Linux, exits 0 cleanly.release/aspire-internal-notify-validationmarker, then closed it in the same build viagh issue close.