Hi all, I opened an INFRA ticket on this topic, and according to the reply, the INFRA team has enabled this setting for us. Now new contributors only need to be approved for CI for their first PR. once the first PR got merged, then CIs on future PRs can automatically run without committers to approve.
Matthew or other contributors can you try and verify? I will need to get back to the INFRA team. Cheers, Yicong Huang [email protected] On May 7, 2026 at 10:43 PM -0700, Xinyuan Lin <[email protected]>, wrote: > +1 > > Sincerely, > > Xinyuan Lin > > On Thu, May 7, 2026 at 22:13 Jiadong Bai <[email protected]> wrote: > > > +1 > > > > Best regards, > > Jiadong Bai > > > > On Mon, May 4, 2026 at 10:37 PM Zuozhi Wang <[email protected]> wrote: > > > > > > I also like and support this. It makes sense and reduce unnecessary > > > > frictions. > > > > > > > > Best > > > > Zuozhi > > > > > > > > On Mon, May 4, 2026 at 10:30 PM Chen Li <[email protected]> wrote: > > > > > > > > > > I support this change because it can make it easier for > > > > > > non-committers > > to > > > > > > contribute. > > > > > > > > > > > > Chen Li > > > > > > > > > > > > On Tue, May 5, 2026 at 1:00 AM Yicong Huang <[email protected]> > > > > > > wrote: > > > > > > > > > > > > > > Hi Texera dev, > > > > > > > > > > > > > > > > > > > > > > > > I'd like to propose a change to our GitHub Actions > > > > > > > > configuration on > > > > > > > > apache/texera to reduce friction for non-committer contributors. > > > > > > > > > > > > > > > > *Background:* Currently, the ASF GitHub Actions policy requires > > > > committer > > > > > > > > approval for all outside collaborators, meaning every push from > > > > > > > > a > > > > > > > > non-committer's fork needs approval before CI runs. This leads > > > > > > > > to > > slow > > > > > > > > feedback and unnecessary work for committers. > > > > > > > > > > > > > > > > *Proposal:* Ask ASF Infra to change to: "Require approval for > > > > first-time > > > > > > > > contributors." This means that after a contributor's initial PR > > > > approval, > > > > > > > > their subsequent pushes and future PRs would trigger CI > > automatically. > > > > > > > > Committers still have visibility, and Infra can revert if > > > > > > > > needed. > > > > > > > > > > > > > > > > As a project, we need to follow certain requirements that are > > > > > > > > called > > > > out > > > > > > > > here - > > > > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Finfra.apache.org%2Fgithub-actions-policy.html&data=05%7C02%7Cyiconghuang%40umass.edu%7C7738af65750a494307a308deacc4b909%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639138158079814319%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iU8xNDYfv8eJ2Ix84c6%2F9POWNhGQBpiQqpG%2FnqbCma0%3D&reserved=0 > > > > > > > > I have > > > > > > > > confirmed > > > > > > > > that: > > > > > > > > - GitHub does not pass repository secrets to runners on fork PRs > > > > > > > > (regardless of whether the workflow file references > > `secrets.*`). > > > > > > > > GITHUB_TOKEN is provided but with read-only permissions on fork > > > > > > > > PRs. > > > > > > > > - Workflows that intentionally need write privileges in PR > > context > > > > > > > > (auto-assign, lint-pr, pr-labeler) use `pull_request_target`, > > > > > > > > which runs in the base-branch context and is unaffected by the > > > > > > > > approval-policy setting. > > > > > > > > - Workflows that touch sensitive secrets (build-and-push-images, > > > > > > > > create-release-candidate, direct-backport-push) are gated on > > > > > > > > `workflow_dispatch` / `push` and are not reachable from fork > > PRs > > > > > > > > at all. > > > > > > > > > > > > > > > > *Precedent:* Several ASF projects have made this switch via > > > > > > > > Infra > > Jira, > > > > > > > > including Apache ShardingSphere and Apache Druid. > > > > > > > > - Apache ShardingSphere — > > > > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-24389&data=05%7C02%7Cyiconghuang%40umass.edu%7C7738af65750a494307a308deacc4b909%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639138158079837503%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=mmFeSZsIbaPmzp21b%2BW1BpuKK%2BEIaiVsIj6M9DerEu8%3D&reserved=0 > > > > > > > > - Apache Druid — > > > > > > > > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FINFRA-24657&data=05%7C02%7Cyiconghuang%40umass.edu%7C7738af65750a494307a308deacc4b909%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C639138158079856626%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Fcu4xseLVO0NetHRSOEG03VdC02YmbKfMDT9Ri3011w%3D&reserved=0 > > > > > > > > > > > > > > > > Please share your thoughts. If no-one objects within three > > > > > > > > days, I’ll > > > > > > > > assume lazy consensus and open a ticket to INFRA. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Yicong Huang > > > > > > > > > > > > > > > > > > > >
