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