> Le 13 nov. 2023 à 21:32, Petr Štetiar <yn...@true.cz> a écrit : > > Thibaut <ha...@slashdirt.org> [2023-11-13 17:26:44]: > > Hi, > >> In any case, another way to tackle this problem would be to switch from >> continuous builds that starve the build resources to periodic builds that >> don’t (e.g. once a week), > > other options: > > * add more build workers :-) > * use different GitPoller polling interval settings > (master=5 minutes, 23.05=12 hours, 22.03=24 hours)
GitPoller accepts a single poll interval. What you’re suggesting would require separating each branch, i.e. returning to the previous situation. It would also entirely defeat the purpose of prioritizing branches at the Scheduler level. Also note that even with a 24h poll interval you could still starve the master builds. Which is why I think either we accept the current situation as being « as designed », or we switch to a periodic build schedule (which imho makes a lot more sense considering that build resources aren’t infinitely expandable). This would have the added benefit of ensuring *consistency* across targets, i.e. ensuring that whichever commit is built is built on *all* targets. Currently master will typically build and produce images for different commits across targets when there is a lot of commit activity. Cheers _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
