Hi Krisztian, Could you describe which flows you are referring to?
Rust builds are taking 4-6m on non-(windows/mac) and 8-15m on windows/mac, with almost immediate feedback. E.g. I force-pushed recently https://github.com/apache/arrow/pull/9089 and the first complete test came 5m later. One hypothesis is that, on personal repos, many builds are being triggered when any change happens. On my repo, R <https://github.com/jorgecarleitao/arrow/actions/runs/463436428>, Python <https://github.com/jorgecarleitao/arrow/actions/runs/463436416>, C++ <https://github.com/jorgecarleitao/arrow/actions/runs/463436422>, Java JNI <https://github.com/jorgecarleitao/arrow/actions/runs/463436419>, C GLib and Ruby <https://github.com/jorgecarleitao/arrow/actions/runs/463436420> jobs ran when a Rust-only change was force pushed into a branch. Another hypothesis is that there are too many builds being triggered with a blanket `ci/*`, which covers all languages, and thus, when changing the comment bot, they all get triggered. What I usually do when playing with builds that can't be tested on my personal repo (e.g. because they require credentials), is to delete all unrelated workflows during testing, and then checkout them when the PR is ready. A bit hackish I must say, but works. Best, Jorge On Tue, Jan 5, 2021 at 1:34 PM Krisztián Szűcs <szucs.kriszt...@gmail.com> wrote: > Hi, > > I'm concerned about the overall feedback time we have on pull requests. > I have a simple PR to make the comment bot working again, but no > builds are running even after 30 minutes. > I can see 2-4 running builds, which will make our work much harder > right before the release. > > I wasn't following the build queue's state lately, but I think we > should consolidate the build configurations. > Possible candidates are the PR* workflows and good to have tests which > we could trigger on master instead. > > Opinions? > > Regards, Krisztian >
