Pre-Master checks (Was: Nightlies)
ggreif at gmail.com
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.
> 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
>> | -----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
More information about the ghc-devs