Re: Please stop committing on a broken build! ([Testbot] Plone 5.0 - Python 2.7 - Build # 1925 - Regression! - 6 failure(s))

Am 22.03.2014 20:19, schrieb Gil Forcada:
> El dv 21 de 03 de 2014 a les 09:27 +0100, en/na Timo Stollenwerk va
> escriure:
>> Am 21.03.2014 08:38, schrieb Laurence Rowe:
>>>     We can't just merge features and then keep the build broken for weeks.
>>>     People are committing anyways, breaking more stuff without notice and in
>>>     the end someone has to clean up that mess. The longer we keep the build
>>>     broken the harder it gets...
>>>
>>>     I try to keep track and remind people if they break things, but that
>>>     only works well if the build is green in the first place.
>>>
>>>
>>> Would it be possible to get tests running on feature branches as well as
>>> master / version branches? It seems unavoidable that occasionally
>>> checkins will break the build, but if those checkins are always made to
>>> a feature branch and merging of the feature to master happens only after
>>> looking at the build status then master should stay green. (Ideally one
>>> first merges from master to the feature branch to ensure the merge back
>>> is clean.)
>>>
>>> I realise the above is very tricky for a system as complex as Plone, but
>>> I've found it to be a great help in my (much smaller) current project.
>>
>> This is what I would love to have. Though, as you said, this is not
>> trivial to implement.
>>
>> Cheers,
>> Timo
> 
> Hi all,
> 
> My 0,5 cents (and 100+ words) about it:
> 
> What we have at the company I work works quite well for us (a simplified
> version of [1] actually and modified to fit in Plone below):
> - master branch should never fail and is only used to merge already
> proved changes (i.e. you usually never push commits there)
> - a develop branch is used to do you day to day commits (or feature
> branches if your changes are big enough)
> - once your feature branch is complete and all tests passes you should
> be able to update the branch in buildout.coredev (develop branch)
> - if that still works you can rebase buildout.coredev master branch into
> develop branch (so make both branches point to the same commit)
> 
> Regarding PLIPs, we already have jenkins jobs for that, isn't it? Maybe
> we should extend the PLIP definition to also say that a jenkins job
> needs to be created for it.

That should be indeed best practice.

> And to top it all, it would be cool if we have a branch in
> buildout.coredev called "tests-passed" this is updated only by jenkins
> once a buildout.coredev specific build is green. Then all PLIPs jenkins
> jobs could be instrumented to checkout buildout.coredev on that specific
> branch and then run the tests for the given PLIP they are supposed to
> run tests for.

We experimented with KGS (know good set) Jenkins jobs to run single
package tests. We always store the last green build (buildout, versions,
checkouts) and run the package tests against that KGS.

Unfortunately that approach failed because it seems that the coredev
buildout is to fragile (fails because of version conflicts, timeouts,
etc.). We just have too many packages that are poorly isolated from each
other with too many dependencies.

We have to work on better solutions. Though, time is limited. If anybody
is interested in improving the PLIP jobs for instance, don't hesitate to
contact me. :)

We currently have two approaches to generate PLIP jobs.

1) Generate a PLIP job TTW with mr.roboto:

https://github.com/plone/mr.roboto

2) Generate PLIP jobs manually with collective.recipe.jenkinsjob:

https://github.com/plone/jenkins.plone.org/blob/master/jenkins-jobs.cfg

Cheers,
Timo

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech