This is an automated email from the ASF dual-hosted git repository. potiuk pushed a commit to branch fork-ci-5-docs in repository https://gitbox.apache.org/repos/asf/airflow.git
commit e9d1bb4705bc76ef356e9a5fc39909dc2b6abcf7 Author: Jarek Potiuk <[email protected]> AuthorDate: Tue Oct 20 23:14:01 2026 +0200 Say when fork CI applies in the contributor docs While the gate is off, a contributor outside the pilot who enabled fork CI as the docs said got CI twice on every pull request. The docs now say fork CI applies to pilot participants and use fork ci pull requests until it is switched on for everyone, and the maintainer docs cover the needs project ci label, the CI passed status and why removing fork ci required is not enough. Generated-by: Claude Opus 5 --- contributing-docs/05_pull_requests.rst | 15 ++++++++------- contributing-docs/18_contribution_workflow.rst | 12 +++++++----- contributing-docs/25_maintainer_pr_triage.md | 11 ++++++++--- 3 files changed, 23 insertions(+), 15 deletions(-) diff --git a/contributing-docs/05_pull_requests.rst b/contributing-docs/05_pull_requests.rst index d4e548f370a..c7fee6d2677 100644 --- a/contributing-docs/05_pull_requests.rst +++ b/contributing-docs/05_pull_requests.rst @@ -94,13 +94,14 @@ these guidelines: The Airflow repo uses `GitHub Actions <https://help.github.com/en/actions>`_ to run the tests and `codecov <https://codecov.io/gh/apache/airflow>`_ to track - coverage. Unless you are a committer, a collaborator or a member of an exempted organisation, - enable the ``Tests (AMD)`` workflow in your fork and every push to your fork runs CI for free - (committers and collaborators keep it disabled, so their pushes do not run CI twice). Pull - requests labelled ``fork ci required`` take their CI result from your fork - and stay in draft until that run is green; see - `CI in your fork <18_contribution_workflow.rst#ci-in-your-fork>`__ and run ``breeze ci audit`` - to check your setup. + coverage. Fork CI is being piloted: it applies to pilot participants and to pull requests a + maintainer labels ``use fork ci``, and to every external contributor only once it is switched + on for everyone. Until then, enabling the ``Tests (AMD)`` workflow in your fork outside the + pilot runs CI twice for each pull request, in your fork and in apache/airflow. When fork CI + applies to you, enable that workflow and every push to your fork runs CI for free; pull + requests labelled ``fork ci required`` take their CI result from your fork and stay in draft + until that run is green. See `CI in your fork <18_contribution_workflow.rst#ci-in-your-fork>`__ + and run ``breeze ci audit``, which tells you whether fork CI applies to you yet. Also we advise to install locally `prek hooks <08_static_code_checks.rst#prek-hooks>`_ to apply various checks, code generation and formatting at the time you make a local commit - which gives you near-immediate feedback on things you need to fix before you push your code to the PR, or in diff --git a/contributing-docs/18_contribution_workflow.rst b/contributing-docs/18_contribution_workflow.rst index 112a825f332..6a82d88a9a6 100644 --- a/contributing-docs/18_contribution_workflow.rst +++ b/contributing-docs/18_contribution_workflow.rst @@ -43,8 +43,8 @@ In general, your contribution includes the following stages: 2. Create a `local virtualenv <07_local_virtualenv.rst>`_, initialize the `Breeze environment <../dev/breeze/doc/README.rst>`__, and install `prek tool <08_static_code_checks.rst#prek-hooks>`__. - Set up the ``upstream`` and ``origin`` remotes, enable CI in your fork and check the result - with ``breeze ci audit``, as described in `CI in your fork`_. + Set up the ``upstream`` and ``origin`` remotes and check them with ``breeze ci audit``; if + fork CI applies to you (see `CI in your fork`_), enable CI in your fork as described there. 3. Join `devlist <https://lists.apache.org/[email protected]>`__ and set up a `Slack account <https://s.apache.org/airflow-slack>`__. @@ -144,9 +144,11 @@ Set up your checkout and fork once: 1. Name your remotes as described in `Git remote naming conventions <10_working_with_git.rst>`__: ``upstream`` for ``apache/airflow`` and ``origin`` for your fork. -2. Unless you are a committer, a collaborator or a member of an exempted organisation, enable the - ``Tests (AMD)`` workflow in your fork. GitHub disables workflows in new forks. Committers and - collaborators keep it disabled, so their pushes do not run CI twice, unless they joined the pilot: +2. If fork CI applies to you, enable the ``Tests (AMD)`` workflow in your fork: today that means + you joined the pilot or a maintainer labelled your pull request ``use fork ci``; once fork CI is + switched on for everyone, it means you are not a committer, a collaborator or a member of an + exempted organisation. GitHub disables workflows in new forks. Otherwise keep it disabled, so + your pushes do not run CI twice: .. code-block:: bash diff --git a/contributing-docs/25_maintainer_pr_triage.md b/contributing-docs/25_maintainer_pr_triage.md index 2196f8db177..8e2b861a57f 100644 --- a/contributing-docs/25_maintainer_pr_triage.md +++ b/contributing-docs/25_maintainer_pr_triage.md @@ -265,9 +265,14 @@ for them, and the triage skill must treat those pull requests as out of scope fo Everything else the skill does (quality criteria, pings, suspicious-change flags) applies as usual. The `Fork CI / Tests (AMD)` commit status shows the fork CI state and links to the run in the fork. To move a single pull request back to project CI, add `use project ci`; the reconciler -releases it on its next run. Pull requests that change CI-defining files stay in draft even when -the fork run is green, and are reported to `internal-airflow-ci-cd` for a maintainer to review and -run project CI with `use project ci`. See +releases it on its next run; removing `fork ci required` by hand is not enough, the next run +labels a gated pull request again. Adding the label does not start project CI by itself: re-run +the pull request's latest `Tests (AMD)` run (`gh run rerun <run-id> -R apache/airflow`, or +**Re-run all jobs** on the run's page), or ask the author to push. Pull requests that change CI-defining files stay in draft even +when the fork run is green and are labelled `needs project ci`, for a maintainer to review and run +project CI with `use project ci`. When the fork run is green and trusted, the reconciler also posts +the `CI passed` status the merge ruleset requires, so these pull requests can be merged or +auto-merged without project CI. See [Fork CI for external contributors](../dev/breeze/doc/ci/08_fork_ci_for_external_contributors.md). ## For contributors
