Baseline-version release workflow opens a new PR per release instead of updating the existing open one

[radical]

Summary

The release workflow that bumps PackageValidationBaselineVersion opens a brand-new PR for every release instead of updating an already-open baseline PR. This leaves a trail of stale, superseded baseline PRs that have to be closed by hand.

Repro

1. Run the release workflow (.github/workflows/release-github-tasks.yml, baseline-pr job) for consecutive patch releases.
2. Observe the PRs it creates:
   • Update PackageValidationBaselineVersion to 13.4.1 #17882 — Update PackageValidationBaselineVersion to 13.4.1 (closed)
   • Update PackageValidationBaselineVersion to 13.4.2 #17887 — Update PackageValidationBaselineVersion to 13.4.2 (closed)
   • Update PackageValidationBaselineVersion to 13.4.3 #18026 — Update PackageValidationBaselineVersion to 13.4.3 (open)

Expected vs. actual

Expected: If a baseline-update PR is already open, the workflow updates that PR (new version bump pushed onto it) rather than opening another one. At most one open baseline PR at a time.

Actual: A new PR is opened for each release. The "Check for Existing Baseline PR" step keys off the version-specific branch name update-baseline-${release_version}, so it only matches a PR for the same version and never finds the previous release's still-open PR. Superseded baseline PRs accumulate and must be closed manually.

cc @joperezr

[joperezr]

🤖 Aspire triage pass — 2026-06-12 22:49 UTC

Area: area-engineering-systems
Kind: bug
Repro: yes-minimal — see the Repro section of the issue body (PRs #17882, #17887, #18026 cited as evidence of the duplication pattern)
Affected version(s): N/A — release-tooling workflow (.github/workflows/release-github-tasks.yml), not a shipped Aspire package version
Severity: S4 — engineering-systems polish; no customer impact, only creates manual cleanup work for maintainers when superseded baseline PRs accumulate

Urgency: ⚪ backlog — no milestone
Reason: workflow-only annoyance with no customer/runtime impact and an obvious manual workaround (close stale PRs); does not meet the 13.4.x servicing bar (not a 13.4 regression in product behavior) and not a vNext priority.

Suggested owner(s): @joperezr (score 6)
Evidence:

• joperezr authored 2 merged PRs labeled area-engineering-systems in the last 90d (top non-bot, non-author contributor in that area)
• Reporter (excluded as author) is the most active recent contributor in this area but cannot self-own per scoring rules
• CODEOWNERS does not list a specific owner for .github/workflows/release-github-tasks.yml

Confidence: medium
Needs human?: no

Dry-run mode — no labels or milestone applied. Reply /triage apply to promote, or edit and reapply.