[JBoss JIRA] (JBIDE-15472) Improve visibility for developers when test failures persist for multiple builds (Jenkins emails are ignored)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15472?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15472:
----------------------------------------
I'm not sure it's necessary to have this automated with a script.
Just planning weekly 30 minutes from someone in the team to review Jenkins builds and send a report or open a bug to components in error would be enough.
[~maxandersen] IMO, it's just a matter of assigning this task to someone, and creating a Zimbra event to make sure it's done regularly.
> Improve visibility for developers when test failures persist for multiple builds (Jenkins emails are ignored)
> -------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15472
> URL: https://issues.jboss.org/browse/JBIDE-15472
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build
> Reporter: Nick Boldt
>
> First iteration: https://issues.jboss.org/browse/JBIDE-15470, as generated by this: https://github.com/jbdevstudio/jbdevstudio-ci/blob/master/bin/createTestF...
> [~maxandersen] said:
> {quote} i would put the details in attachment i think. its a bit overloaded otherwise I think,
> btw. is this something you will run when you find a failed buid or did you say you would detect when hit a certain amont of fail you generate it ?
> if auto generated shuold take care to not keep opening new jiras again andagain ;)
> maybe add a "watermark" to detect stil open test failure jiras
> {quote}
> Idea here is to run this tool as needed when I notice that builds which are supposed to be frozen and stable are showing test failures persisting for multiple builds. Could also run against master jobs, but less critical.
> Not sure what you mean by a watermark, or how that would be implemented. Please elaborate.
> As this is purely a workflow optimization, it does NOT affect docs.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-15135) Attach metadata during assembly instead of publish time
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15135?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-15135:
-----------------------------------
Fix Version/s: 4.2.x
(was: 4.2.0.Alpha1)
> Attach metadata during assembly instead of publish time
> -------------------------------------------------------
>
> Key: JBIDE-15135
> URL: https://issues.jboss.org/browse/JBIDE-15135
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Mickael Istria
> Fix For: 4.2.x
>
>
> In order to make it easier to deal with Nexus and to have an homogeneous way to access build metadata (commit id), it would be interesting to move creation of metadata at assembly time (same time as when we create index and so on), and put it directly into the site.
> Then whether we use Nexus or a home-made publication, we are sure that we can access metadata whenever we can access the binaries.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16137) webservices component build slow during tests
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16137?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-16137:
-----------------------------------
Fix Version/s: 4.2.0.Alpha1
> webservices component build slow during tests
> ---------------------------------------------
>
> Key: JBIDE-16137
> URL: https://issues.jboss.org/browse/JBIDE-16137
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, webservices
> Affects Versions: 4.2.0.Alpha1
> Environment: Luna 4.4 M3 TP
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Fix For: 4.2.0.Alpha1
>
> Attachments: jstack-43357.txt
>
>
> when reaching the tests on org.jboss.tools.ws.creation.core.tests, a workbench window appears but nothing is drawn and the build is *very* slow
> {code}
> [INFO] Command line:
> /bin/sh -c cd /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test && /Library/Java/JavaVirtualMachines/jdk1.7.0_12.jdk/Contents/Home/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=macosx -Dosgi.ws=cocoa -Dosgi.arch=x86_64 '-javaagent:/Users/xcoulon/.m2/repository/org/jacoco/org.jacoco.agent/0.6.1.201212231917/org.jacoco.agent-0.6.1.201212231917-runtime.jar=destfile=/Users/xcoulon/code/jbosstools/jbosstools-webservices/target/jacoco.exec,append=true,includes=org.jboss.tools.ws.creation.core*' -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XstartOnFirstThread '-Djbosstools.test.jre.6=${jbosstools.test.jre.6}' '-Djbosstools.test.jre.5=${jbosstools.test.jre.5}' -Djbosstools.test.jboss.home.4.2=/Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/requirements/jboss-4.2.3.GA -Dusage_reporting_enabled=false -Dorg.jboss.tools.tests.skipPrivateRequirements=true -Dorg.eclipse.ui.testsDisableWorkbenchAutoSave=true -Dosgi.clean=true -jar /Users/xcoulon/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.0.v20130327-1440/org.eclipse.equinox.launcher-1.3.0.v20130327-1440.jar -data /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work/data -install /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work -configuration /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work/configuration -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/surefire.properties
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-16220:
-----------------------------------
Fix Version/s: 4.2.x
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.x
>
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16137) webservices component build slow during tests
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16137?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16137:
----------------------------------------
[~bfitzpat] [~xcoulon] Has it happened again since we merged workaround for JBIDE-16161 ? Last CI build is blue and took only 28 minutes.
> webservices component build slow during tests
> ---------------------------------------------
>
> Key: JBIDE-16137
> URL: https://issues.jboss.org/browse/JBIDE-16137
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, webservices
> Affects Versions: 4.2.0.Alpha1
> Environment: Luna 4.4 M3 TP
> Reporter: Xavier Coulon
> Assignee: Xavier Coulon
> Attachments: jstack-43357.txt
>
>
> when reaching the tests on org.jboss.tools.ws.creation.core.tests, a workbench window appears but nothing is drawn and the build is *very* slow
> {code}
> [INFO] Command line:
> /bin/sh -c cd /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test && /Library/Java/JavaVirtualMachines/jdk1.7.0_12.jdk/Contents/Home/jre/bin/java -Dosgi.noShutdown=false -Dosgi.os=macosx -Dosgi.ws=cocoa -Dosgi.arch=x86_64 '-javaagent:/Users/xcoulon/.m2/repository/org/jacoco/org.jacoco.agent/0.6.1.201212231917/org.jacoco.agent-0.6.1.201212231917-runtime.jar=destfile=/Users/xcoulon/code/jbosstools/jbosstools-webservices/target/jacoco.exec,append=true,includes=org.jboss.tools.ws.creation.core*' -Xms512m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=256m -XstartOnFirstThread '-Djbosstools.test.jre.6=${jbosstools.test.jre.6}' '-Djbosstools.test.jre.5=${jbosstools.test.jre.5}' -Djbosstools.test.jboss.home.4.2=/Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/requirements/jboss-4.2.3.GA -Dusage_reporting_enabled=false -Dorg.jboss.tools.tests.skipPrivateRequirements=true -Dorg.eclipse.ui.testsDisableWorkbenchAutoSave=true -Dosgi.clean=true -jar /Users/xcoulon/.m2/repository/p2/osgi/bundle/org.eclipse.equinox.launcher/1.3.0.v20130327-1440/org.eclipse.equinox.launcher-1.3.0.v20130327-1440.jar -data /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work/data -install /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work -configuration /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/work/configuration -application org.eclipse.tycho.surefire.osgibooter.uitest -testproperties /Users/xcoulon/code/jbosstools/jbosstools-webservices/tests/org.jboss.tools.ws.creation.core.test/target/surefire.properties
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running org.jboss.tools.ws.creation.core.test.JBossWSCreationCoreTestSuite
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-15907) Adds source plugins into JBT's Target-platforms update site
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15907?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-15907:
----------------------------------------
FYI, if you use jbosstools-multiple.target in your IDE, you have access to Eclipse sources.
Sources are lost when aggregating the "multiple" target into unified one. For JBoss Tools, we encourage developers to use the mutliple target in their IDE so they have access to sources.
If you tweak you TP pom to:
1. First generate a multiple (consuming jbosstools-multiple)
2. Then aggregate this multiple (to get a "all-in-one" site)
Then output of 1 is a .target file that can be imported in IDE and will contain sources.
> Adds source plugins into JBT's Target-platforms update site
> -----------------------------------------------------------
>
> Key: JBIDE-15907
> URL: https://issues.jboss.org/browse/JBIDE-15907
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: integration-platform, target-platform
> Reporter: Paul Richardson
> Fix For: 4.2.x
>
>
> The integration-stack target uses
> http://download.jboss.org/jbosstools/targetplatforms/jbosstoolstarget/4.3... to provide the base eclipse dependencies, eg. org.eclipse.jface. This update site does not include source plugins.
> For higher level projects, like Teiid Designer, that use the IS as its target platform, this means that eclipse classes do not find nor display their source. This makes debugging UI elements a lot harder.
> Thus, can source plugins be included in the integration-stack base.target via the above dependent update site?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (JBIDE-16308) Cannot start JBT 4.2.0.Alpha1 on Fedora 19
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16308?page=com.atlassian.jira.plugi... ]
Mickael Istria updated JBIDE-16308:
-----------------------------------
Fix Version/s: 4.2.0.Alpha2
(was: 4.2.0.Alpha1)
> Cannot start JBT 4.2.0.Alpha1 on Fedora 19
> ------------------------------------------
>
> Key: JBIDE-16308
> URL: https://issues.jboss.org/browse/JBIDE-16308
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, xulrunner
> Affects Versions: 4.2.0.Alpha1
> Environment: JBT 4.2.Alpha1, L64, Fedora 19, 64-bit, Open JDK 1.7
> Reporter: Jiri Peterka
> Priority: Blocker
> Fix For: 4.2.0.Alpha2
>
> Attachments: hs_err_pid17371.log, hs_err_pid18745.log
>
>
> Installing JBT on Eclipse -4.4.M4- 4.4.M3 JEE package (linux_64), after JBT installation update site and restart I have:
> {code}
> !ENTRY org.eclipse.osgi 4 0 2013-12-16 15:35:03.535
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> java.lang.OutOfMemoryError: GC overhead limit exceeded
> at java.util.ArrayList.iterator(ArrayList.java:814)
> at org.apache.felix.resolver.ResolverImpl.mergeUses(ResolverImpl.java:962)
> at org.apache.felix.resolver.ResolverImpl.calculatePackageSpaces(ResolverImpl.java:787)
> at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:252)
> at org.eclipse.osgi.container.ModuleResolver$ResolveProcess.resolve(ModuleResolver.java:652)
> at org.eclipse.osgi.container.ModuleResolver.resolveDelta(ModuleResolver.java:75)
> at org.eclipse.osgi.container.ModuleContainer.resolveAndApply(ModuleContainer.java:454)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:412)
> at org.eclipse.osgi.container.ModuleContainer.resolve(ModuleContainer.java:402)
> at org.eclipse.osgi.container.Module.start(Module.java:406)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1530)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1510)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1481)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1424)
> at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
> at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
> at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> {code}
> Even if I raise a memory for JVM, Eclipse doesn't start but not error message is written
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months