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 <david@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
