[potiuk]

When the Auto approve workflow runs workflow leaves an external contributor's runs for a maintainer, the contributor only sees the need workflow approval label, with no reason. A comment per PR would notify every subscriber, so this shows the reason as a commit status instead.

• Pending status with the reason. The head commit gets a pending Workflow approval status, for example Waits for a maintainer: it changes CI definition files: .github/… (cut to GitHub's 140 characters). It links to the "CI workflow runs of external contributors" section of the contributing docs. It is not a required check and does not block merging. The same status is not written twice, because every tick decides again on the runs of the last 24 hours.
• Cleared when the runs start. GitHub has no event for approving runs, but a waiting run never starts. The new mark-workflow-runs-approved.yml follows Tests (AMD) runs of fork PRs reaching in_progress. It turns the status green and removes the label, whether a maintainer or the workflow approved the runs. It doesn't need to list the ~1.8k waiting runs. It is a single ubuntu-slim step of plain gh api calls: no checkout, no Breeze, and the contributor-chosen head branch reaches the script only through env:.
• Race with a manual approval. A maintainer can approve after the tick listed the runs but before it writes the label and status. So whenever the tick writes either one, it checks the runs again and clears both if none still waits; the failure path does the same.
• Status lookups are paginated. The fork CI reconciler posts one status per job, so Workflow approval can be past the first page.

Known limitation (documented): only a started Tests (AMD) run clears the status, so a PR that removes or renames that workflow keeps its label and pending status. Such a PR changes CI definition files and gets a maintainer's review anyway.

Docs updated: contributing-docs/05_pull_requests.rst, contributing-docs/25_maintainer_pr_triage.md, dev/breeze/doc/08_ci_tasks.rst, dev/breeze/doc/ci/05_workflows.md and dev/breeze/doc/ci/08_fork_ci_for_external_contributors.md.

Testing: uv run --project dev/breeze pytest dev/breeze/tests/test_workflow_run_approval.py (145 passed). Static checks pass, including zizmor and yamllint on the new workflow; the Markdown link check was skipped locally because it needs Docker. I ran the new workflow's read calls (PR lookup by head, paginated status lookup) read-only against a labelled PR on apache/airflow. workflow_run only triggers from the default branch, so the in_progress trigger and the two write calls can only be seen after merge; a report-only dispatch of Auto approve workflow runs shows the pending-status decisions.

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: Claude Opus 5 following the guidelines

---

• Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
• For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
• When adding dependency, check compliance with the ASF 3rd Party License Policy.
• For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

🤖 Generated with Claude Code

[github-actions]

The re-run of the jobs stopped by EC2 Spot interruptions finished: attempt 2 failed.

[github-actions]

Backport successfully created: v3-4-test

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status	Branch	Result
✅	v3-4-test