hi Josep > Do you see any potential impact if we backport the change to those?
In my opinion, the main concern is that non-trunk PRs can't effectively leverage the cache, meaning they require more time and resources to run CI. Additionally, github-ci is triggered by trunk branch only, and we have not tested it on non-trunk branch yet. Given that 3.9.0 and 3.8.1 releases are processing, we could continue using Jenkins CI to avoid the additional overhead of backporting. By the way, we'll eventually need to backport GitHub CI to the non-trunk branches once the 4.1 branch is created. Best, Chia-Ping Chia-Ping Tsai <chia7...@gmail.com> ζΌ 2024εΉ΄9ζ26ζ₯ ι±ε δΈε4:15ε―«ιοΌ > Thanks to David for providing us with an improved CI! > > Cheers, > Chia-Ping > > David Arthur <mum...@gmail.com> ζΌ 2024εΉ΄9ζ26ζ₯ ι±ε δΈε8:51ε―«ιοΌ > >> Today, we disabled the Jenkins build on trunk. With this change, we should >> now be expecting all green status checks on PRs before merging. Of course, >> flaky tests still exist, but generally speaking we should have green >> builds >> (see KIP-1090 for some plans on flaky tests). >> >> Any committer or "collaborator" (as defined in .asf.yaml) is able to >> manually re-run a GitHub Action via the UI. >> >> For non-committers, someone must approve the workflow. There is a >> "approve-workflows.py" script in committer-tools to help with this. I'm >> still investigating options to improve this. >> >> We will keep the Jenkins build enabled for 3.9 and other release branches. >> >> Cheers, >> David A >> >
