Re: Continuous Testing of Git on Windows

Johannes Schindelin [off-list ref] writes:

That is why I taught the Git for Windows CI job that tests the four
upstream Git integration branches to *also* bisect test breakages and then
upload comments to the identified commit on GitHub

Good.  I do not think it is useful to try 'pu' as an aggregate and
expect it to always build and work [*1*], but your "bisect and
pinpoint" approach makes it useful to identify individual topic that
brings in a breakage.  I wouldn't be surprised if original submitter
and I were the only two people who actually compiled the patches on
a topic in isolation while a topic is in 'pu', and chances are that
these two people didn't try their builds on Windows.  A CI like this
one will help the coverage to stop premature topics from advancing
to 'pu' without getting any Windows exposure.

Thanks.


[Footnote]

*1* The reason why topics not in 'next' but in 'pu', especially the
    ones merged near the tip of 'pu', exist in 'pu' are because they
    are interesting enough and could be polished to become eligible
    for 'next' but known to be premature for 'next' yet.  They are
    there primarily to give human contributors an easier way to
    download them as a whole and help polish them.  And I have to be
    selective when I queue things on 'pu'; it is not like I have
    infinite amount of time to pick up any cruft that is sent to the
    list.

Hi,

On Mon, 13 Feb 2017, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

That is why I taught the Git for Windows CI job that tests the four
upstream Git integration branches to *also* bisect test breakages and
then upload comments to the identified commit on GitHub

Good.  I do not think it is useful to try 'pu' as an aggregate and
expect it to always build and work [*1*], but your "bisect and
pinpoint" approach makes it useful to identify individual topic that
brings in a breakage.

Sadly the many different merge bases[*1*] between `next` and `pu` (which
are the obvious good/bad points for bisecting automatically) bring my
build agents to its knees. I may have to disable the bisecting feature as
a consequence.

Ciao,
Johannes

Footnote *1*: There are currently 21, some of which stemming back from a
year ago. For bisecting, they all have to be tested individually, putting
a major dent into bisect's otherwise speedy process.