Pre-Master checks (Was: Nightlies)

Tue Feb 4 21:42:19 UTC 2014

On 2/4/14, Carter Schonwald <carter.schonwald at gmail.com> wrote:
> one point in the design space (mind you one i'm not going to advocate) is
> the testing / merging workflow that the Mozilla folks are doing for rust.
>  Every patch / pull request gets tested by their build bot before merging.
> Does make the commits on master look pretty mess / mergy though.
>
> mind you its a bit tightly coupled to github, but some of the ideas *might*
> be a good strawman.  Likewise, how does eg LLVM/Clang manage its
> testing infrastructure?  How does GCC manage it?

LLVM devs need to run 'make check' before committing to the repo. This
runs 8000+ tests in about 30 seconds.

Then there is the bot infrastructure at http://lab.llvm.org:8011/console ,
and who breaks a target is alerted by mail. But this applies to all
committers whose changes entered into (slow) builds. It is not
commit-exact, though better on the fast bots.

Cheers,

    Gabor

>
>
> On Tue, Feb 4, 2014 at 12:56 PM, Simon Peyton Jones
> <simonpj at microsoft.com>wrote:
>
>> I can see advantages here, similar to Richard.  I'm just a bit worried
>> about keeping all those branches straight in my head.
>>
>> Who names all these temporary branches?  Does someone delete them so they
>> don't accumulate and dominate the branch list?
>>
>> Would need careful documenting, so that new people know exactly what to
>> do.
>>
>> Simon
>>
>> | -----Original Message-----
>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
>> | Joachim Breitner
>> | Sent: 04 February 2014 09:42
>> | To: ghc-devs at haskell.org
>> | Subject: Re: Pre-Master checks (Was: Nightlies)
>> |
>> | Hi,
>> |
>> | Am Dienstag, den 04.02.2014, 08:04 +0000 schrieb Simon Peyton Jones:
>> | > I want just to say thank you for thinking about this.  We badly need
>> | better nightly-builds for GHC, on a variety of platforms
>> | > a) to identify regressions, preferably to the actually commit that
>> | >    caused it, so Austin's big red message can go to the right person
>> |
>> | I believe we can do better, so that Austin's big red message does not
>> | have to be written in the first place.
>> |
>> | Here is what I have in mind, and I'll volunteer to implement it if
>> | people think it is a good idea and I get the resources/permissions:
>> |
>> | Proposal
>> | ~~~~~~~~
>> |
>> | Nobody gets to push to master directly. Instead, every push to master
>> | is
>> | diverted¹ to a temporary branch "validating/<some id>". One of our
>> | servers detects the appearance of such a branch and will
>> |  * check it out,
>> |  * validate it,
>> |  * if ok: check if master can still be fast-forward'ed to it,
>> |  * if yes: push to master.
>> |
>> | If it does not validate, or if master has changed in between, the
>> | branch
>> | will be moved to failed/<some id>, and a message is sent to the pushing
>> | developer², including a tail of the log and a link to the full log.
>> |
>> | Systems can fail, and maybe nothing validates anymore for reasons not
>> | easily fixable. For that case, a backdoor is available: Pushes to the
>> | branch "master-unchecked" will be moved to master, well, unchecked.
>> |
>> | Benefits:
>> |  * It is guaranteed that master has validated at least once somewhere.
>> |    I.e. no need to ask on the mailing list "does master validate for
>> | you
>> |    right now?"
>> |  * It is now ok to do changes that are "obviously correct" (comment
>> |    changes, removing dead code, code reformatting) without having
>> |    to validate manually, which _saves developer time_ (our most
>> | precious
>> |    resource).
>> |
>> | Downsides:
>> |  * When two commits are racing for master, one will be rejected for
>> |    being a non-fast-forward commit. The user will then have to merge
>> |    or rebase and try again.
>> |    But: The same would be true if he was validating locally (unless he
>> |    does not validate the merge/rebase, in which case we are again where
>> |    we don't want to be: Unvalidated versions in master.)
>> |
>> |
>> | Is this something you would what, or could live with?
>> |
>> | If it is technically feasible (given our hardware constraints,
>> | repository structure and git's feature) is a different question, which
>> | needs to be discussed afterwards.
>> |
>> | Greetings,
>> | Joachim
>> |
>> |
>> |
>> | ¹ Might not be possible transparently
>> | (http://stackoverflow.com/questions/21362833), but for the sake of
>> | argument and workflow design, assume it was.
>> | ² As an approximation: The committer of the latest patch.
>> |
>> | PS: I'm also considering (but not pushing hard) for a stronger variant
>> | as follows. We do not need to discuss that now and should, if at all,
>> | start the with the proposal above. I'm just adding it to show where
>> | this
>> | is going ...
>> |
>> | Stronger proposal
>> | ~~~~~~~~~~~~~~~~~
>> |
>> |         Every commit in master needs to be validated!
>> | I tend to make sure that all patches on my branch validate individually
>> | (git rebase -i -x "./validate" is a great tool here, you should use it!
>> | ). Contributors who do not want to go through that trouble should then
>> | use "git merge --squash" to produce a single commit from their branch.
>> |
>> | This would make the git history more useful for things like bitsecting.
>> |
>> |
>> |
>> | --
>> | Joachim Breitner
>> |   e-Mail: mail at joachim-breitner.de
>> |   Homepage: http://www.joachim-breitner.de
>> |   Jabber-ID: nomeata at joachim-breitner.de
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>