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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
