You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "potiuk (via GitHub)" <gi...@apache.org> on 2026/10/15 22:46:52 UTC
[PR] Document fork CI for contributors and maintainers [airflow]
potiuk opened a new pull request, #74825:
URL: https://github.com/apache/airflow/pull/74825
Stacked on #74823. Part 5 of 5 of the AIP-120 implementation (design: #73378); this PR's base is the previous branch, so the diff shows only this layer.
Adds "CI in your fork" to the contribution workflow (setup, `breeze ci audit`, what contributors see, joining and leaving the pilot), links it from the quick starts, PR guidelines and git conventions, adds the reconciler/triage ownership split to the maintainer triage doc, and the fork push run to `05_workflows.md`.
---
##### Was generative AI tooling used to co-author this PR?
- [X] Yes — Claude Code (Opus 5)
Generated-by: Claude Code (Opus 5) following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions)
🤖 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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "shahar1 (via GitHub)" <gi...@apache.org>.
shahar1 commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4301818385
##########
contributing-docs/05_pull_requests.rst:
##########
@@ -94,8 +94,11 @@ 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. You can set up both for free on your fork. It will help you make sure you do not
- break the build with your PR and that you help increase coverage.
+ coverage. Enable the ``Tests (AMD)`` workflow in your fork and every push to your fork runs
Review Comment:
This tells every reader to enable `Tests (AMD)`, but `breeze ci audit` fails committers, collaborators and exempted-org members who do. Maybe scope it to contributors whose PRs use fork CI?
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,63 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. Enable the ``Tests (AMD)`` workflow in your fork. GitHub disables workflows in new forks:
Review Comment:
Same as in `05_pull_requests.rst`: step 2 asks everyone to enable the workflow, and the caveat that committers and collaborators keep it disabled only comes at line 182, after step 3's audit would already fail them.
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,63 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. Enable the ``Tests (AMD)`` workflow in your fork. GitHub disables workflows in new forks:
+
+ .. code-block:: bash
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is marked ready and
Review Comment:
The reconciler marks a PR ready only when the bot drafted it (`_is_bot(pr.last_draft_actor)`), so a PR the author drafted stays a draft and gets no label.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4330956947
##########
contributing-docs/05_pull_requests.rst:
##########
@@ -94,8 +94,13 @@ 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. You can set up both for free on your fork. It will help you make sure you do not
- break the build with your PR and that you help increase coverage.
+ coverage. Unless you are a committer, a collaborator or a member of an exempted organisation,
Review Comment:
Fixed. `05_pull_requests.rst` and "CI in your fork" now say that fork CI applies to pilot participants and `use fork ci` PRs until it's switched on for everyone, and that enabling the workflow outside that runs CI twice. `breeze ci audit` tells you which case you're in. Also from a second review: the maintainer docs now say that adding `use project ci` doesn't start project CI by itself. Re-run the PR's latest `Tests (AMD)` run, or have the author push.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4304447607
##########
contributing-docs/03_contributors_quick_start.rst:
##########
@@ -237,6 +237,16 @@ Forking and cloning Project
to clone the repo locally (you can also do it in your IDE - see the `Using your IDE`_
chapter below)
+4. Add ``apache/airflow`` as the ``upstream`` remote, following the
+ `Git remote naming conventions <10_working_with_git.rst>`__:
+
+ .. code-block:: bash
+
+ git remote add upstream https://github.com/apache/airflow.git
Review Comment:
Added: if you use SSH with GitHub, use `git@github.com:apache/airflow.git` instead; `breeze ci audit` recognises both. fc720e5253.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
contributing-docs/05_pull_requests.rst:
##########
@@ -94,8 +94,11 @@ 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. You can set up both for free on your fork. It will help you make sure you do not
- break the build with your PR and that you help increase coverage.
+ coverage. Enable the ``Tests (AMD)`` workflow in your fork and every push to your fork runs
Review Comment:
Agreed. It's now scoped: unless you're a committer, a collaborator or a member of an exempted organisation, enable `Tests (AMD)`; committers and collaborators keep it disabled. fc720e5253.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,63 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. Enable the ``Tests (AMD)`` workflow in your fork. GitHub disables workflows in new forks:
Review Comment:
Moved the caveat into step 2, which now says who enables the workflow and that a committer in the pilot enables it too. fc720e5253.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,63 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. Enable the ``Tests (AMD)`` workflow in your fork. GitHub disables workflows in new forks:
+
+ .. code-block:: bash
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is marked ready and
Review Comment:
Right. The doc now says a green run labels the PR `ready for maintainer review` and marks it ready only if the monitor drafted it; a PR you drafted yourself stays a draft until you mark it ready. fc720e5253.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk merged PR #74825:
URL: https://github.com/apache/airflow/pull/74825
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "shahar1 (via GitHub)" <gi...@apache.org>.
shahar1 commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4301698456
##########
contributing-docs/03_contributors_quick_start.rst:
##########
@@ -237,6 +237,16 @@ Forking and cloning Project
to clone the repo locally (you can also do it in your IDE - see the `Using your IDE`_
chapter below)
+4. Add ``apache/airflow`` as the ``upstream`` remote, following the
+ `Git remote naming conventions <10_working_with_git.rst>`__:
+
+ .. code-block:: bash
+
+ git remote add upstream https://github.com/apache/airflow.git
Review Comment:
(nit:?) SSH compatibility?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "Andrushika (via GitHub)" <gi...@apache.org>.
Andrushika commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4312034486
##########
contributing-docs/05_pull_requests.rst:
##########
@@ -94,8 +94,13 @@ 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. You can set up both for free on your fork. It will help you make sure you do not
- break the build with your PR and that you help increase coverage.
+ coverage. Unless you are a committer, a collaborator or a member of an exempted organisation,
Review Comment:
We might need to say this applies only once the gate is on, or when you are in the pilot. While `enabled = false`, a non-committer who follows this gets fork CI and project CI on every PR, and `breeze ci audit` says fork CI is not required yet.
---
Drafted-by: Claude Code (Opus 5.5); reviewed by @Andrushika before posting
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "shahar1 (via GitHub)" <gi...@apache.org>.
shahar1 commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4367538830
##########
dev/breeze/doc/ci/05_workflows.md:
##########
@@ -92,6 +93,30 @@ all dependencies to latest versions and build images with them. This way we chec
dependencies are upgraded. This can also be forced by setting the `upgrade to newer dependencies`
label in the PR if you are a committer and want to force dependency upgrade.
+Every pull request run of `ci-amd.yml` starts with the `Fork CI gate` job. For pull requests
+whose CI runs in the contributor's fork (AIP-120), the gate skips `build-info` and therefore
+everything after it, so the run finishes in seconds; see
+[Fork CI for external contributors](08_fork_ci_for_external_contributors.md).
+
+## Fork push run
+
+These runs are triggered by a push to any branch of a contributor's fork in which the
+`Tests (AMD)` workflow is enabled. They run in the fork, on GitHub's public runners and with the
+fork's token, and are how pull requests labelled `fork ci required` get their CI result. They are
+selected like a pull request run: the changed files come from comparing the pushed commit with
+`apache/airflow` (`main`, or the release branch the pushed branch name starts with), so a fork
Review Comment:
**minor** — The compare base is not derived from the branch name. `ci_commands.py` calls `get_fork_changes(fork_owner=fork_owner, sha=commit_ref, base=default_branch)`, and the `fork_compare.py` docstring says "`base` is the branch line the pushed code belongs to (breeze's default branch at that commit), which a branch name cannot be trusted to tell" (design doc 08 says the same). A backport branch such as `backport-<sha>-v3-1-test` also does not *start* with the release branch. Maybe: "(`main`, or the release branch the pushed code was cut from, as breeze's default branch at that commit records it)".
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
Review Comment:
**major** — This `...` underline is the first third-level title style in the file, so the existing `Newsfragments` subsection (underlined `~~~`, line 294) becomes level 4 under a level-2 section. docutils on this head reports `294: (ERROR/3) Inconsistent title style: skip from level 2 to 4 ... Established title styles: = - .` and `253: (ERROR/3) Unknown target name: "newsfragments"`, and drops the section, so `` `Newsfragments`_ `` (line 253) and the `18_contribution_workflow.rst#newsfragments` link in AGENTS.md stop resolving. The layer-4 file parses clean. Using the file's existing third-level style fixes it:
```suggestion
~~~~~~~~~~~~~~~
```
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. 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
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is labelled
+``ready for maintainer review``, and marked ready for review if the monitor drafted it; a pull
+request you drafted yourself stays a draft until you mark it ready. A pull request whose fork CI does not run for 7 days is
+closed with an explanation; you can reopen it after setting up fork CI. If your pull request changes
+files that define what CI runs, such as ``.github/``, ``dev/breeze/`` or ``scripts/ci/``, a green
+fork run is not enough: a maintainer reviews the change and runs project CI for it.
+
+**Joining the pilot.** Open a pull request that adds your GitHub login to the ``[pilot]`` table in
+``.github/fork-ci-gate.toml``, with a join instant after the expected merge, for example the next day
+at 00:00 UTC:
+
+.. code-block:: toml
+
+ [pilot]
+ "your-login" = 2026-10-20T00:00:00Z
Review Comment:
**nit** — `2026-10-20T00:00:00Z` is already in the past, so a contributor copying the example verbatim gets rejected by `check-fork-ci-gate-config` (`if base_pilot.get(login) != joined_at and joined_at <= now:`). A placeholder such as `YYYY-MM-DDT00:00:00Z` would avoid that.
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. 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
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is labelled
+``ready for maintainer review``, and marked ready for review if the monitor drafted it; a pull
Review Comment:
**nit** — `classify` only labels a green pull request that is ready: `ready = not pr.is_draft or plan.draft is False`. So a pull request the author drafted gets no `ready for maintainer review` label until the author marks it ready; the next reconcile run then adds it. The earlier thread fixed the draft half of this, not the label half; `25_maintainer_pr_triage.md:257` ("adds it when the fork run is green") has the same gap. Maybe: "...a pull request you drafted yourself stays a draft, and gets the label, once you mark it ready."
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Document fork CI for contributors and maintainers [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on code in PR #74825:
URL: https://github.com/apache/airflow/pull/74825#discussion_r4367844662
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
Review Comment:
Thanks, switched to `~~~`. docutils parses the file clean again, so `Newsfragments` resolves.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
dev/breeze/doc/ci/05_workflows.md:
##########
@@ -92,6 +93,30 @@ all dependencies to latest versions and build images with them. This way we chec
dependencies are upgraded. This can also be forced by setting the `upgrade to newer dependencies`
label in the PR if you are a committer and want to force dependency upgrade.
+Every pull request run of `ci-amd.yml` starts with the `Fork CI gate` job. For pull requests
+whose CI runs in the contributor's fork (AIP-120), the gate skips `build-info` and therefore
+everything after it, so the run finishes in seconds; see
+[Fork CI for external contributors](08_fork_ci_for_external_contributors.md).
+
+## Fork push run
+
+These runs are triggered by a push to any branch of a contributor's fork in which the
+`Tests (AMD)` workflow is enabled. They run in the fork, on GitHub's public runners and with the
+fork's token, and are how pull requests labelled `fork ci required` get their CI result. They are
+selected like a pull request run: the changed files come from comparing the pushed commit with
+`apache/airflow` (`main`, or the release branch the pushed branch name starts with), so a fork
Review Comment:
Took your wording: "the release branch the pushed code was cut from, as breeze's default branch at that commit records it".
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. 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
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is labelled
+``ready for maintainer review``, and marked ready for review if the monitor drafted it; a pull
Review Comment:
Reworded along your lines, and fixed the same gap in `25_maintainer_pr_triage.md`.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
##########
contributing-docs/18_contribution_workflow.rst:
##########
@@ -126,6 +127,68 @@ to make them immediately visible in the environment.
6. Open your IDE (for example, PyCharm) and select the virtual environment you created
as the project's default virtual environment in your IDE.
+CI in your fork
+...............
+
+Pull requests from contributors who are not committers or collaborators are moving to running
+their CI in the contributor's own fork, on GitHub's free runners, instead of on the shared CI
+capacity of the Apache Software Foundation (`AIP-120
+<https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks>`__).
+CI on a public fork costs you nothing and has no minute limit; it runs on every push to your
+fork, so you get feedback before a maintainer looks at your pull request. The change is being
+piloted: until it is switched on for everyone, it applies to pilot participants (see below) and
+to pull requests a maintainer labels ``use fork ci``.
+
+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. 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
+
+ gh workflow enable ci-amd.yml -R <you>/airflow
+
+ If the workflow is missing, your fork's ``main`` is older than it; sync it first with
+ ``gh repo sync <you>/airflow --branch main``.
+
+3. Check everything at once. ``breeze ci audit`` prints one row per check and the command that fixes
+ anything missing; ``--fix`` runs those commands after asking:
+
+ .. code-block:: bash
+
+ breeze ci audit
+
+When fork CI applies to your pull request, it is labelled ``fork ci required`` and kept in draft
+until the ``Tests (AMD)`` run in your fork for its latest commit is green. A
+``Fork CI / Tests (AMD)`` status on the pull request links to that run, and one comment on the pull
+request explains the current state. Once the run is green the pull request is labelled
+``ready for maintainer review``, and marked ready for review if the monitor drafted it; a pull
+request you drafted yourself stays a draft until you mark it ready. A pull request whose fork CI does not run for 7 days is
+closed with an explanation; you can reopen it after setting up fork CI. If your pull request changes
+files that define what CI runs, such as ``.github/``, ``dev/breeze/`` or ``scripts/ci/``, a green
+fork run is not enough: a maintainer reviews the change and runs project CI for it.
+
+**Joining the pilot.** Open a pull request that adds your GitHub login to the ``[pilot]`` table in
+``.github/fork-ci-gate.toml``, with a join instant after the expected merge, for example the next day
+at 00:00 UTC:
+
+.. code-block:: toml
+
+ [pilot]
+ "your-login" = 2026-10-20T00:00:00Z
Review Comment:
Now `YYYY-MM-DDT00:00:00Z`.
---
Drafted-by: Claude Code (Opus 5); reviewed by @potiuk before posting
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org