Pre-Master checks (Was: Nightlies)

[Mateusz Kowalczyk]

On 04/02/14 09:41, Joachim Breitner wrote:
> 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.
> 
> 
> 
> 
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
> 

You mention that it's enough for one machine to validate the patch. What
if the change was for example to fix something on ARM (where builds take
a long time) and has no effect on x86? The x86 machine is likely to come
through first and give you the OK, pushing to master something that's
effectively not checked. In fact, the fastest slave is likely to come
through first every time and if it validates there (for example, I hear
that 64-bit Linux is the golden platform for validate), it will be
pushed to master.

I think the proposal needs an enhancement: ability to specify which
platform the commit needs to validate on (i.e. even if i686 comes
through first, we'll wait for ARM anyway) before being pushed in.

-- 
Mateusz K.