> I too made this realization while reviewing the application. I concur it
> is something that we should try and mitigate. Sending a canary patch
> through once-a-day, or on any fixed time period, doesn’t quite seem
> sufficient. We have many commits per day and immediately switch to them as
> they are seen.
>
> The system itself needs to be able to simply create a job and test
> master/HEAD whenever it wishes. Then use the outcome of the job to decide
> whether to wait for a new HEAD before pulling more CF entries. Or,
> alternatively, continue using the “previous” commit as the base until
> master/HEAD changes again and it can evaluate the new proposed base.
>
> There are some other variations on these to consider as well. Like, the
> first patch (or multiple due to concurrency) to fail on a new commit base
> waits for a test of the base to complete before being marked failed or
> aborted.
>
> That said, adding a “null” CF entry to the queue right now is doable and
> virtually cost-free.
Unfortunately cfbot seems to sleep 10 days or so once a test fails
(and if patch is not get updated). So it's not automatically doable
today. I need manual updating of the patch.
> While it may not provide complete benefit there
> likely would be some.
Yeah. But I still think even once a day test is useful because it will
reduce the number of commits to git bisect.
> Anyone could increment the version number and email
> the thread to release a new canary on-demand. It would also provide some
> data/feedback while designing and implementing a more integrated solution.
Okay, next time I face a cfbot error like I explained upthread, I will
create a "canary".
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
