Makes sense & thanks for handling this. I would particularly highlight the possible workflow change:
The "standard" workflow* of maintaining branches on your own fork and opening a PR to the main fork is now at a slight disadvantage. Committers will benefit, at least slightly, from opening branches on the main repo. I don't intend to change my workflow (yet), but will take some time to evaluate how much it matters, and expecting that we will continue to improve the situation. If I understand correctly, self-hosted runners + pull_request trigger will still be able to run cloud-based ITs. Kenn *I checked the last 20+ PRs I reviewed and they all used this workflow, even though almost all of them were from committers and PMC. On Fri, Oct 2, 2026 at 6:33 AM Danny McCormick via dev <[email protected]> wrote: > Hey everyone, as part of a security hardening effort, I recently moved > most of our GitHub Actions workflows from the pull_request_target trigger > to the pull_request trigger (example PR moving some workflows - > https://github.com/apache/beam/pull/40360). > > *Expected Impact* > > The expected impact of this change should be relatively small, but there > is some loss/change of functionality: > > 1. Pull requests created from forks (as opposed to branches on the > apache/beam repo) will not have access to workflow secrets. For a few > workflows, this means a couple of tests will be skipped. For all workflows, > this means that they will not be able to write back to the build cache. > They should still be able to read from the build cache. > 2. Using comments to trigger workflow reruns will no longer work. I have > not seen much use of this functionality in a while anyways. > 3. Workflows from non-committers may need to be manually approved more > often before running. > > If you see impacts outside of this, please let me know. > > *Why this change now (feel free to ignore this section if you don't care > about the rationale)* > > While there were no known exploits in our previous CI infrastructure, > pull_request_target was drawing a lot of security reports and did open us > up to higher potential for an accidental security bug. In fact, the feature > is considered risky even by GitHub and they are intentionally > reducing/restricting its usage. > https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target > has > more details. The Beam PMC was having a hard time staying on top of these > reports, and this should simplify the associated toil while reducing our > overall risk profile. > > At the same time, some of the problems that the pull_request_target > functionality was originally introduced to solve are less relevant - for > example, as a repo we are much less reliant on secrets than we used to be. > Given the relatively small impact of the change, now seemed like a good > time to make the move. > > Please let me know if you have any questions or concerns. > > Thanks, > Danny >
