potiuk opened a new pull request, #75832: URL: https://github.com/apache/airflow/pull/75832
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? - [X] Yes (please specify the tool below) Generated-by: Claude Opus 5 following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#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](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). * For significant user-facing changes create newsfragment: `{pr_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/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](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
