Hi Ash, Please address the larger issue in a separate reply.
I do not intend to be confrontational, and I never called you a liar. My goal is simply to demonstrate how our proposal benefits both Airflow and other ASF projects. This approach is already used by Apache SeaTunnel, Apache DataFusion, and Apache Arrow. In fact, the Apache DataFusion team has submitted a shared action for this: https://github.com/apache/infrastructure-actions/tree/main/fork-ci (a simpler version that we plan to improve based on our Airflow experience and eventually adopt). As Shahar noted during the last dev call, ASF Infrastructure is encouraging PMCs to adopt this approach due to upcoming per-project limits on shared runners. It is recommended to prevent foundation-wide CI overload, even if it adds some complexity. Regarding the run you linked: good point, and thank you for the correction—I misremembered how that worked. We used that method for about three years under pull_request_target before moving away from it to align with ASF security best practices (and then it changed back to PR ). Given how quickly our main branch moves, PRs that fall behind usually require a rebase before CI runs anyway. so practically it has very little impact - also because conflicts would catch most issues and canary builds are designed to catch any "fall-through" for that reason, so practical impact of that is very small. That said, this is easy to fix. I will incorporate your feedback and address all the issues you raised in the new workflow. I appreciate your attention to detail and thorough review—it helps us build better workflows. Best regards, Jarek > It’s my test PR https://github.com/apache/airflow/pull/76536, go back > through the edit history of the comment from github-actions > Yep. This is what we will do to improve it. > It literally _is not_. I did the _exact_ steps I listed below, and project > CI never ran or blocked it from merging. Thank you so much for calling me a > liar first and not spending the time to actually look at the issue I > highlighted. It really makes me feel appreciated. > > >> > >> So the sequence is: > >> > >> fork CI goes green > >> -> add "use project ci" > >> -> close/reopen > >> -> approve with auto-merge on, or merge, before project CI finishes > >> a-> it merges on the fork's "CI passed". > Only maintainers and collaborators can add labels on PRs and do close/re-open, secondly your PR did **not** modify CI workflows. This means the "Fork CI" runs using the same workflows we have defined. You are completely mistaken about the value of "fork CI" vs "apache CI" - and your case literally does not show any scenario where trust boundaries are broken. Please explain in detail if you have an exact scenario where trust boundaries are broken, but based on what you wrote it does not prove anything. I **never** called you a liar Ash. I just do not understand what use case you are talking about and how it makes things less safe - your example is not clear, and does not explain how a malicious (or sloppy) external contributor would cause anything more than they can do today. Maybe you can help me (and others) to understand - show it on a separate test PR, and explain step-by-step what is different between what they do currently vs. what they will be able to do in the new workflow? That would be very useful to fix any issues if there are any. > > >> [^1] It currently lives at > dev/breeze/doc/ci/08_fork_ci_for_external_contributors.md - is that it’s > final home? > > > > Any other proposals? This is not part of the AIP discussion - this is > more of a small implementation detail. > > Do we need it there at all? We already have > https://github.com/apache/airflow/blob/main/contributing-docs/18_contribution_workflow.rst#ci-in-your-fork > (Thanks Andrew for pointing that out). > We. can certainly consolidate and review the documentation. In fact one of the SKILLs I am planning to add to Magpie is to do just that: review the projects' documentation, find out the inconsistencies and repetitions, remove those and add "per area documentation" that makes sense and is usable by both humans and agents. So this might be one of the first things we use it for. Since we have a lot of useful feedback - my plans is to apply all that (but also others - Andrrew, Henry, Shahar - maybe you can take the problems raised by Ash and create PRs fixing those -that will be useful, and once we are done and test it all in the pilot - we will re-cast the vote. Thanks, Ash, for pointing all those out, but I propose let's focus on making it work well rather than questioning something that 3 other ASF projects already use and data shows that this is the "most impactful" change on the queue usage they have done. J.
