[jbosstools-dev] Block PRs for merge untill the Jenkins build is successful

[Andre Dietisheim]

Radim, these are exactly the EGit failures that I was referring to. The 
one you pasted is among the ones that occurr. But afaik the failures are 
not consistent and they dont happen in the old jenkins.

Am 10.05.17 um 10:41 schrieb Radim Hopp:
> Last time I sent PR to openshift repo I had to be really patient, 
> because the build was failing on "java.io.IOException: Could not 
> delete file 
> /mnt/hudson_workspace/workspace/jbosstools-openshift-Pull-Request/tests/org.jboss.tools.openshift.egit.test/target/work/data/Project-1494366069560". 
> I had to run the PR check job ~5 times for it to finally pass.
>
> On Wed, May 10, 2017 at 10:38 AM Andre Dietisheim <adietish at redhat.com 
> <mailto:adietish at redhat.com>> wrote:
>
>     I agree in the principle. But for the approach to be successfull
>     we need our new new jenkins to be rocksolid which it isnt for now.
>     Our EGit tests fail randomly on it while they pass on the old jenkins.
>
>     Am 10.05.17 um 10:17 schrieb Dmitrii Bocharov:
>>     Jeff, for this purpose we can think of some special comment for
>>     such PRs, that would allow to merge them (like /testPR/ for a new
>>     build). As far as i know it's possible.
>>
>>     On Wed, May 10, 2017 at 9:01 AM, Jean-Francois Maury
>>     <jmaury at redhat.com <mailto:jmaury at redhat.com>> wrote:
>>
>>         I'm ok with that rule except for one case when the pr is done
>>         before the version bump has been merged then the Jenkins
>>         build will fail because of the baseline check so maybe we
>>         need to update the pr Jenkins build
>>
>>         Jeff
>>
>>         Le 9 mai 2017 23:10, "Mickael Istria" <mistria at redhat.com
>>         <mailto:mistria at redhat.com>> a écrit :
>>
>>             FYI, not merging the broken patches is the policy
>>             followed by most Eclipse.org projects and overall, none
>>             of this project has complained from a reduced
>>             productivity; on the contrary, catching and fixing issues
>>             immediately on the right context has improved quality and
>>             reduced the necessary amount of quick fix patches (which
>>             are actually quite time consuming and stressful for their
>>             low added-value).
>>             So I think if it works for Eclipse.org projects, it can
>>             work for JBoss Tools.
>>
>>             Cheers,
>>             Mickael
>>
>>             _______________________________________________
>>             jbosstools-dev mailing list
>>             jbosstools-dev at lists.jboss.org
>>             <mailto:jbosstools-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>>
>>
>>
>>
>>     _______________________________________________
>>     jbosstools-dev mailing list
>>     jbosstools-dev at lists.jboss.org
>>     <mailto:jbosstools-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
>     _______________________________________________
>     jbosstools-dev mailing list
>     jbosstools-dev at lists.jboss.org <mailto:jbosstools-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/jbosstools-dev
>
> -- 
>
> RADIMHOPP
>
> RED HAT JBOSS DEVELOPER STUDIO QUALITY ASSURANCE
>
> Red HatCzech s.r.o. <https://www.redhat.com/>
>
> rhopp at redhat.com <mailto:rhopp at redhat.com> IM:rhopp
>
> <https://red.ht/sig> 	
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
> @redhatway <https://twitter.com/redhatway>@redhatinc 
> <https://instagram.com/redhatinc>@redhatsnaps 
> <https://snapchat.com/add/redhatsnaps>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosstools-dev/attachments/20170510/da3dc246/attachment-0001.html