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.
--
-David
david@pgmasters.net