Repository navigation
Stop labelling fork CI PRs that change CI files for workflow approval - #76289
Conversation
A pull request whose CI runs in the contributor's fork gets its project CI runs held when it changes CI definition files. It got the "need workflow approval" label for that, and "needs project ci" once its fork run was green. Without "use project ci", approving the held runs does not start project CI, so the first label asked maintainers for a step that does not help. It also stayed on pull requests whose fork run failed.
github-actions
Bot
added
fork ci required
|
Your CI change needs a maintainer. CI for this pull request runs in your fork, and the workflow runs it starts in apache/airflow are approved automatically while they only run the fork CI gate. This pull request changes files that define what CI runs:
Such a change can make project CI run on the project's runners, so its workflow runs in apache/airflow wait for a maintainer to review the change and approve them. CI in your fork is not affected, and its result stays visible on this pull request. Pull requests from contributors run their CI in the contributor's own fork. GitHub Actions is free and has no minute limit on public forks, while the CI capacity of the Apache Software Foundation is shared by every ASF project and is finite. This comment was posted automatically by the fork CI monitor from templates drafted with an AI-assisted tool, so it may contain mistakes. An Apache Airflow maintainer, a real person, will review the pull request once its fork CI is green. Why the first pass is automated. |
|
Project CI in use. A maintainer added the This comment was posted automatically by the fork CI monitor from templates drafted with an AI-assisted tool, so it may contain mistakes. An Apache Airflow maintainer, a real person, will review the pull request once its fork CI is green. Why the first pass is automated. |
github-actions
Bot
added
the
needs project ci
Pull request was converted to draft
Dev-iL
added
the
use project ci
github-actions
Bot
removed
the
needs project ci
github-actions
Bot
removed
the
fork ci required
…apache#76289) A pull request whose CI runs in the contributor's fork gets its project CI runs held when it changes CI definition files. It got the "need workflow approval" label for that, and "needs project ci" once its fork run was green. Without "use project ci", approving the held runs does not start project CI, so the first label asked maintainers for a step that does not help. It also stayed on pull requests whose fork run failed. (cherry picked from commit 4c110e6)
…apache#76289) A pull request whose CI runs in the contributor's fork gets its project CI runs held when it changes CI definition files. It got the "need workflow approval" label for that, and "needs project ci" once its fork run was green. Without "use project ci", approving the held runs does not start project CI, so the first label asked maintainers for a step that does not help. It also stayed on pull requests whose fork run failed. (cherry picked from commit 4c110e6)
…apache#76289) A pull request whose CI runs in the contributor's fork gets its project CI runs held when it changes CI definition files. It got the "need workflow approval" label for that, and "needs project ci" once its fork run was green. Without "use project ci", approving the held runs does not start project CI, so the first label asked maintainers for a step that does not help. It also stayed on pull requests whose fork run failed. (cherry picked from commit 4c110e6)
…#76289) (#76582) A pull request whose CI runs in the contributor's fork gets its project CI runs held when it changes CI definition files. It got the "need workflow approval" label for that, and "needs project ci" once its fork run was green. Without "use project ci", approving the held runs does not start project CI, so the first label asked maintainers for a step that does not help. It also stayed on pull requests whose fork run failed. (cherry picked from commit 4c110e6) Co-authored-by: Andrew Chang <69671930+Andrushika@users.noreply.github.com>
Background
GitHub holds the CI runs of a fork pull request until a maintainer approves them.
auto-approve-workflow-runsapproves the safe runs every 15 minutes. It labels the other pull requestsneed workflow approval. If a pull request runs its CI in the contributor's fork, the gate in itsTests (AMD)run skips project CI. The workflow holds this run only if the pull request changes CI definition files.Why
Approving that held run does not start project CI. On #76136, the approved run only executed
Fork CI gate(run). Project CI starts only after a maintainer addsuse project ci. When the fork run is green, the fork CI reconciler asks for that step withneeds project ci. #76267 has both labels for the same change. #75743 keepsneed workflow approvalwhile its fork run fails.What
The workflow still holds these runs and sets the pending
Workflow approvalstatus. It no longer addsneed workflow approval. If the label is already there, it removes it.The new tests in
test_workflow_run_approval.pyfail without the change. This conflicts with #76282 inworkflow_run_approval.pyand the fork CI doc. I will rebase when it merges.related: #76282
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Claude Opus 5.5) following the guidelines
🤖 Generated with Claude Code