Hi all, Today is branch/codefreeze day as planned [1]. Special note: Newcomers to this came is jbosstools-arquillian and jbosstools-aerogear - Snjezan/Gorkem, speak up if any issues doing this. A quick reminder what that means for each component/repo owner: 0) Make sure your component(s) has no remaining jiras for 4.1.0.Beta1 in jira. If anything left over (besides New and noteworthy writing issues) that would be done in respins which we wish to keep to a bare minimum, hopefully completely avoid. 1) Make sure your component uses 4.1.0.Beta1-SNAPSHOT as the version for jboss tools parent. Should look something like this: <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.1.0.Beta1-SNAPSHOT</version> </parent> 2) Make sure your component builds and passes its tests when run locally. $ mvn clean verify 3) Make a branch for the beta1 builds to use. Most components uses master, thus the steps would be something like: $ git checkout master $ git pull origin master $ git checkout -b jbosstools-4.1.0.Beta1x $ git push origin jbosstools-4.1.0.Beta1x 4) Respond to this mail before end of today with a "All Done for component: <your component>" or "<your component> cannot branch/freeze today because of <jira issues> must be done first" Thank you! [1] https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plug... _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Hi all, Today is branch/codefreeze day as planned [1]. Special note: Newcomers to this came is jbosstools-arquillian and jbosstools-aerogear - Snjezan/Gorkem, speak up if any issues doing this. A quick reminder what that means for each component/repo owner: 0) Make sure your component(s) has no remaining jiras for 4.1.0.Beta1 in jira. If anything left over (besides New and noteworthy writing issues) that would be done in respins which we wish to keep to a bare minimum, hopefully completely avoid. 1) Make sure your component uses 4.1.0.Beta1-SNAPSHOT as the version for jboss tools parent. Should look something like this: <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.1.0.Beta1-SNAPSHOT</version> </parent> 2) Make sure your component builds and passes its tests when run locally. $ mvn clean verify 3) Make a branch for the beta1 builds to use. Most components uses master, thus the steps would be something like: $ git checkout master $ git pull origin master $ git checkout -b jbosstools-4.1.0.Beta1x $ git push origin jbosstools-4.1.0.Beta1x 4) Respond to this mail before end of today with a "All Done for component: <your component>" or "<your component> cannot branch/freeze today because of <jira issues> must be done first" Thank you! [1] https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plug... _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Hi all, Today is branch/codefreeze day as planned [1]. Special note: Newcomers to this came is jbosstools-arquillian and jbosstools-aerogear - Snjezan/Gorkem, speak up if any issues doing this. A quick reminder what that means for each component/repo owner: 0) Make sure your component(s) has no remaining jiras for 4.1.0.Beta1 in jira. If anything left over (besides New and noteworthy writing issues) that would be done in respins which we wish to keep to a bare minimum, hopefully completely avoid. 1) Make sure your component uses 4.1.0.Beta1-SNAPSHOT as the version for jboss tools parent. Should look something like this: <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.1.0.Beta1-SNAPSHOT</version> </parent> 2) Make sure your component builds and passes its tests when run locally. $ mvn clean verify 3) Make a branch for the beta1 builds to use. Most components uses master, thus the steps would be something like: $ git checkout master $ git pull origin master $ git checkout -b jbosstools-4.1.0.Beta1x $ git push origin jbosstools-4.1.0.Beta1x 4) Respond to this mail before end of today with a "All Done for component: <your component>" or "<your component> cannot branch/freeze today because of <jira issues> must be done first" Thank you! [1] https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plug... _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

Hi all, Today is branch/codefreeze day as planned [1]. Special note: Newcomers to this came is jbosstools-arquillian and jbosstools-aerogear - Snjezan/Gorkem, speak up if any issues doing this. A quick reminder what that means for each component/repo owner: 0) Make sure your component(s) has no remaining jiras for 4.1.0.Beta1 in jira. If anything left over (besides New and noteworthy writing issues) that would be done in respins which we wish to keep to a bare minimum, hopefully completely avoid. 1) Make sure your component uses 4.1.0.Beta1-SNAPSHOT as the version for jboss tools parent. Should look something like this: <parent> <groupId>org.jboss.tools</groupId> <artifactId>parent</artifactId> <version>4.1.0.Beta1-SNAPSHOT</version> </parent> 2) Make sure your component builds and passes its tests when run locally. $ mvn clean verify 3) Make a branch for the beta1 builds to use. Most components uses master, thus the steps would be something like: $ git checkout master $ git pull origin master $ git checkout -b jbosstools-4.1.0.Beta1x $ git push origin jbosstools-4.1.0.Beta1x 4) Respond to this mail before end of today with a "All Done for component: <your component>" or "<your component> cannot branch/freeze today because of <jira issues> must be done first" Thank you! [1] https://issues.jboss.org/browse/JBIDE#selectedTab=com.atlassian.jira.plug...

base: test fail

Mickael - problem is that these tests passes fine on a local machine.

We would need to apply https://github.com/jbosstools/jbosstools-build/pull/88. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=405456 The test failure at https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... is caused by this bug. Snjeza On 5/21/2013 2:42 PM, Max Rydahl Andersen wrote: > On Tue, May 21, 2013 at 10:46:24AM +0200, Mickael Istria wrote: > > Mickael - problem is that these tests passes fine on a local machine. > > Fails on jenkins which unfortunately keeps being extremly unreliable and slow. > > But Yes - we need to fix these and adjust the tests to not be reliant > on multiple jobs/threads etc. so the tests can run to completeness more reliable. > > thats the worst thing I see in our testsuite, the tests are relying on concurrent jobs > and aren't simply testing a unit of code. it's testing a combination (i.e. big integration test) > and that's not something we should have in our core tests - thats too unreliable. > > /max > >> Hi all, >> >> On 05/18/2013 08:53 PM, Nick Boldt wrote: >>> base: test fail >> Base (which is used by almost all our component) has been red for more >> than a week because of test failures or timeout. It has even been >> branched for a revision that has been red for a week. >> What does that mean? It means that we will create a Beta1 based on a >> component something that either has a bug, or that we don't know >> whether it works or not. If I were Len or anyone else from the QE >> team, I would be really annoyed by the fact that QE is about to be >> shipped a build where base component is not guaranteed to work... >> >> This is a general bad habit we have, as a team. regarding automated >> tests. Automated tests, on whichever component, are here to ensure the >> quality of what we're doing, and to avoid respins or worse, bugs on >> end-usage. >> These failed tests have to take priority #1 when they happen, and you >> should monitor mails from CI or at the CI dashboard to check >> everything you're working on seems to behave well. Leaving jobs into a >> Red state is just taking a huge risk, which can have pretty bad >> consequences (respins) and that will cost much more time and effort to >> fix later. >> >> So please try to keep the CI jobs blue. It's our responsibility to all >> of us to do good stuff, and to ensure we're doing good stuff. >> Cheers, >> -- >> Mickael Istria >> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> >> My blog <http://mickaelistria.wordpress.com> - My Tweets >> <http://twitter.com/mickaelistria> >> _______________________________________________ >> jbosstools-dev mailing list >> jbosstools-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/jbosstools-dev > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 05/22/2013 01:42 PM, Snjezana Peco wrote: > We would need to apply > https://github.com/jbosstools/jbosstools-build/pull/88. See > https://bugs.eclipse.org/bugs/show_bug.cgi?id=405456 > The test failure at > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... > is caused by this bug. The real cause of this issue is xvfb started to provide display for tests, switching to xvnc solves the issue. The same problem was discovered for hibernate tests, even disabling workspace auto save job through plugin_customization.ini didn't solve the issue and build stuck anyway in Display.sleep() method forever.

OK, so the net of this conversation is that the Base job should be switched back to using Xvnc instead of Xvfb? Should we do the same for all the other jobs, or flip them over on a case-by-case basis, only as required?

On 05/23/2013 06:19 AM, Mickael Istria wrote: > On 05/23/2013 03:16 PM, Nick Boldt wrote: >> OK, so the net of this conversation is that the Base job should be >> switched back to using Xvnc instead of Xvfb? Should we do the same >> for all the other jobs, or flip them over on a case-by-case basis, >> only as required? > Xvnc makes (often) some error_code 13 > Xvfb seems to slow down some tests... > > I've merged the PR to disable the workbench autosave job. Let's hope > it's enough for test to run on Xvfb... That didn't work for me in hibernate build, no more Workspace Auto Save Job, but Display.sleep() still called in waitForJobs() method and did not return control back when xvbf used. Denis > -- > Mickael Istria > Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> > My blog <http://mickaelistria.wordpress.com> - My Tweets > <http://twitter.com/mickaelistria> > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> So -1 for the patch, +1 for Xvnc. Most likely it rather related to slave's operation system (OS) and especially to Desktop Environment(DE) configured for xvnc. It could make sense just exclude some hosts from group used to build/test JBD/JBDS

We would need to apply https://github.com/jbosstools/jbosstools-build/pull/88. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=405456 The test failure at https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... is caused by this bug.

Mickael, What "most resent logs" are you talking about? https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBo... is totally blue (3 hrs ago).

Is that new option is for *_41 jobs too or the only xvfb->xvnc was the change there?