Andrushika commented on code in PR #73378: URL: https://github.com/apache/airflow/pull/73378#discussion_r4311745649
########## dev/breeze/doc/adr/0020-run-ci-for-external-contributions-in-forks.md: ########## @@ -0,0 +1,167 @@ +<!-- + Licensed to the Apache Software Foundation (ASF) under one + or more contributor license agreements. See the NOTICE file + distributed with this work for additional information + regarding copyright ownership. The ASF licenses this file + to you under the Apache License, Version 2.0 (the + "License"); you may not use this file except in compliance + with the License. You may obtain a copy of the License at + + http://www.apache.org/licenses/LICENSE-2.0 + + Unless required by applicable law or agreed to in writing, + software distributed under the License is distributed on an + "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + KIND, either express or implied. See the License for the + specific language governing permissions and limitations + under the License. + --> + +<!-- START doctoc generated TOC please keep comment here to allow auto update --> +<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --> + +- [20. Run CI for external contributions in contributor forks](#20-run-ci-for-external-contributions-in-contributor-forks) + - [Status](#status) + - [Context](#context) + - [Decision](#decision) + - [Consequences](#consequences) + +<!-- END doctoc generated TOC please keep comment here to allow auto update --> + +# 20. Run CI for external contributions in contributor forks + +Date: 2026-09-19 + +## Status + +Proposed (pending the outcome of the AIP-120 vote; the implementation ships dormant) + +## Context + +[AIP-120](https://cwiki.apache.org/confluence/spaces/AIRFLOW/pages/451974711/AIP-120+Run+CI+for+external+contributions+in+contributor+forks) +proposes that pull requests from contributors who are not committers, collaborators or +members of an exempted organisation get their CI feedback from GitHub Actions running in the +contributor's own fork, and that project CI in ``apache/airflow`` is reserved for the rest. +The motivation is in the AIP: Airflow is routinely the largest consumer of the shared ASF +GitHub Actions pool by job count, roughly a fifth of externally authored pull requests close +without merging after consuming CI and reviewer attention, and the wait maintainers observe on +their own pull requests is queueing in that shared pool, not execution time. GitHub Actions is +free and unmetered on public repositories, so the cost moved to the contributor is elapsed +time on a 20-job concurrency cap, not money. + +Mechanising this touches four places at once: the trigger and selective-check logic of the +main test workflow, an automated lifecycle for gated pull requests, a way for contributors +to check their setup before pushing, and the contribution documentation. The design is in +[Fork CI for external contributors](../ci/08_fork_ci_for_external_contributors.md). This +record captures the decisions that shape it and the alternatives rejected. + +## Decision + +1. **One eligibility function, one configuration file.** ``fork_ci_gate.decide`` in breeze is + a pure, standard-library-only function over the fields both the workflow event and the + GraphQL API expose. Its configuration is ``.github/fork-ci-gate.toml`` in the repository: + an ``enabled`` switch, an ``enabled_since`` cut-off, ``close_after_days``, the + exempted-organisation allowlist and the ``[pilot]`` table of volunteer contributors. A repository file rather than an Actions variable because + ASF projects cannot self-serve variables and exemption changes deserve a reviewed pull + request. The gate reads the file from the base branch so a pull request cannot alter its + own eligibility. Two labels that only people with triage rights can set override the + automatic decision per pull request: ``use project ci`` and ``use fork ci``. They take + effect whether or not the gate is enabled, which makes ``use fork ci`` the pilot switch. + +2. **Project CI is stopped by a gate job, not by cancellation.** ``ci-amd.yml`` gets a + ``gate`` job that executes the eligibility file directly with the runner's ``python3`` and + makes ``build-info`` conditional on it. Cancelling the run is impossible with the read-only + token a fork pull request gets, and failing the run would attach a misleading red status. + Skipping is silent and cheap. + +3. **Fork pushes run CI with pull-request semantics.** The push trigger becomes ``'**'`` and + the previous branch patterns move into the eligibility function so behaviour in + ``apache/airflow`` is unchanged. In a fork, selective checks compute the change set with the + cross-repository compare API against ``apache/airflow`` (merge-base semantics, no fork sync Review Comment: We might need to decide here how far a branch can be behind `main` before its green fork run counts. The compare uses the merge-base, but the fork run tests the branch head, while project CI tests the PR merged into the current base. Would asking for a rebase when the branch is too far behind make sense, or is a project CI run before merge the intended answer? --- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
