On 2018-03-05 20:49:02 -0500, David Steele wrote: > On 3/5/18 8:33 PM, Thomas Munro wrote: > > On Tue, Mar 6, 2018 at 1:00 PM, David Steele <da...@pgmasters.net> wrote: > >> I've been using commitfest.cputube.org for reference since the last CF, > >> though I'm unsure if it rechecks patches when master changes, so I do > >> that manually. Anyway, that's probably too much to ask since every push > >> to master would set off a 100+ builds on Travis. > >> > >> Maybe just reapply once a day when master changes? And only rebuild if > >> the patch changes? Not perfect, but it would work in most cases. > >> > >> I use Travis for the pgBackRest project, and I try to be considerate of > >> the free resources. I dislike the idea of throwing a ton of builds at > >> them without considering what would be most useful. > > > > It's triggered by new patches AND new commits. Since I want to be > > polite, I try to avoid having more than 2 builds going at a time. > > They generously invite open source projects like us to run up to 5 > > builds concurrently for free, so I thought I was being at least a > > little bit considerate, though I guess I could drop it down to 1. It > > goes in rotating order of Commitfest ID and waits in between to limit > > the rate. The constant stream of both commits and patches during a > > 200+ entry Commitfest mean that it's effectively building around the > > clock and each CF entry gets retested about twice a day. Perhaps I > > could make it smarter... I'll think about that. Thanks! > > Another option would be too look at their graphs and figure out when > their peak times are, then ramp up the builds outside that time. > > Even so, 2 builds at a time sounds pretty moderate to me.
Have we pinged them about what they're ok with? In previous interactions I had with them they were pretty responsive. Greetings, Andres Freund
