Pre-Master checks (Was: Nightlies)

[Simon Marlow]

On 04/02/2014 01:41, Joachim Breitner wrote:
> 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.

The system should try to rebase and re-validate automatically in this 
case.  I think this is pretty important - otherwise pushes can fail for 
random reasons that are no fault of the developer.

Actually I'd even go so far as to say that if the rebase succeeds 
without conflicts then the push should go ahead.  Yes this can introduce 
bugs, but since a validate takes ~30 minutes at a certain rate of 
commits it becomes impossible to push anything if the tree must be 
validated and fast-forwarded to push.

Also, bear in mind that since this stands between a developer and 
getting their changes in, it really must work, all the time.  Be careful 
what you're signing up for :-)  My feeling is that as a first step this 
system should be treated as a validation service: we don't force people 
to use it if they don't want to, so that we can see how well it works 
over time and developers can gradually migrate to using it.  On that 
basis I'd be really happy to see it, and possibly to rely on it more 
over time.

Cheers,
Simon



> 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
>