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