[JBoss JIRA] (JBIDE-23734) dedupe vpe unit test jobs / migrate vpe builds to CCI
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23734?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-23734:
------------------------------------
I agree: for all build and PR jobs, we should be running the {color:green}*QUICK RUNNING*{color} Unit and UI (type 1 and 2) tests.
Then once a week we can run the {color:red}*SLOW RUNNING*{color} ITests (type 3 and 4).
Thanks for moving the views!
So... I guess the next step is to dedupe the .prcheck jobs [1] vs. the -Pull-Request jobs [2] ?
[1] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
[2] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
We should decide if it makes sense to have 1 job per project (server), 1 job per functional grouping (as, archives, jmx, ...), or one MATRIX job per project, broken into functional groupings (eg., like the javaee-tests job [3]). Personally, I like the matrix approach because you can re-run just the failing parts, or run the whole suite for the whole project.
[3] https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
> dedupe vpe unit test jobs / migrate vpe builds to CCI
> -----------------------------------------------------
>
> Key: JBIDE-23734
> URL: https://issues.jboss.org/browse/JBIDE-23734
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, integration-tests
> Affects Versions: 4.4.3.AM1
> Reporter: Nick Boldt
> Assignee: Rastislav Wagner
> Fix For: 4.4.3.Final
>
>
> There are four VPE unit test jobs. We probably only need 2 of those.
> These both run on multiple OSes:
> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
> These probably run the same unit tests, but against master or 4.4.x branches, and are called from the VPE build jobs [1], [2] on Boston MW Jenkins (because the tests were failing to run in Boston):
> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
> [1] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-vpe_master/
> [2] http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-vpe_4.4.neon/
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBTIS-1023) Features and plugins for Fuse tooling have various versions
by Lars Heinemann (JIRA)
[ https://issues.jboss.org/browse/JBTIS-1023?page=com.atlassian.jira.plugin... ]
Lars Heinemann commented on JBTIS-1023:
---------------------------------------
I already provided a PR to return to old naming style without the need to revert the parent pom version.
> Features and plugins for Fuse tooling have various versions
> -----------------------------------------------------------
>
> Key: JBTIS-1023
> URL: https://issues.jboss.org/browse/JBTIS-1023
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: build, distribution
> Affects Versions: 10.1.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Lars Heinemann
> Priority: Blocker
>
> |org.fusesource.ide.camel.editor.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.core.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.jmx.feature|9.1.0.CR1-v20170103-1319-B91|
> |org.fusesource.ide.server.extensions.feature|9.1.0.CR1-v20170105-1331-B91|
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-23811) ZipException in CDICoreBuilder when indexing some Maven artifacts
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23811?page=com.atlassian.jira.plugi... ]
Jeff MAURY commented on JBIDE-23811:
------------------------------------
I cannot reproduce with only a Maven project. How come the CDI builder will be invoked on a Maven project ? I enabled CDI on the project and then the CDI builder appears in the list of builders but even if I do a clean on the project then I can't get the error.
> ZipException in CDICoreBuilder when indexing some Maven artifacts
> -----------------------------------------------------------------
>
> Key: JBIDE-23811
> URL: https://issues.jboss.org/browse/JBIDE-23811
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.4.3.Final
>
>
> it would be nice to provide more information in log such as the classes in inspection by CDI Core Builder.
> Also if there are some issues with those jars, please report bugs to them.
> {noformat}
> !ENTRY org.jboss.tools.common.core 4 0 2017-01-17 11:17:20.815
> !MESSAGE invalid LOC header (bad signature)
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:717)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:419)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433)
> at org.jboss.jandex.Indexer.index(Indexer.java:689)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> {noformat}
> !ENTRY org.jboss.tools.common.model 4 0 2017-01-25 16:11:53.722
> !MESSAGE Exception occurs when reading C:\Users\Aurelien Pupier\.m2\repository\org\apache\aries\blueprint\org.apache.aries.blueprint.core\1.7.1\org.apache.aries.blueprint.core-1.7.1.jar
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(Unknown Source)
> at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(Unknown Source)
> at java.util.zip.InflaterInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at org.jboss.tools.common.model.filesystems.impl.JarAccess.getContent(JarAccess.java:235)
> at org.jboss.tools.common.model.filesystems.impl.JarAccess.isTextEntry(JarAccess.java:266)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.createFileObject(JarFolderImpl.java:95)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.loadChildren(JarFolderImpl.java:78)
> at org.jboss.tools.common.model.impl.RegularObjectImpl.getChildByPathPart(RegularObjectImpl.java:159)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.getChildByPathPart(JarFolderImpl.java:152)
> at org.jboss.tools.common.model.impl.XModelObjectImpl.getChildByPath(XModelObjectImpl.java:347)
> at org.jboss.tools.common.model.impl.XModelObjectImpl.getChildByPath(XModelObjectImpl.java:352)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.readRuntimes(ClassPathMonitor.java:286)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:103)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.jboss.tools.cdi.core.CDICoreBuilder.<init>(CDICoreBuilder.java:101)
> at org.jboss.tools.cdi.core.CDICoreNature.load(CDICoreNature.java:420)
> at org.jboss.tools.cdi.core.CDICoreNature.resolveStorage(CDICoreNature.java:393)
> at org.jboss.tools.cdi.core.CDICoreNature.resolve(CDICoreNature.java:406)
> at org.jboss.tools.cdi.core.CDICorePlugin.getCDI(CDICorePlugin.java:165)
> at org.jboss.tools.cdi.core.CDICorePlugin$RCL.resourceChanged(CDICorePlugin.java:104)
> at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:289)
> at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:152)
> at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:374)
> at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1469)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:46)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBTIS-1023) Features and plugins for Fuse tooling have various versions
by Paul Leacu (JIRA)
[ https://issues.jboss.org/browse/JBTIS-1023?page=com.atlassian.jira.plugin... ]
Paul Leacu commented on JBTIS-1023:
-----------------------------------
Agreed - so the Fuse guys will back off the parent pom and respin their packages for this release and we can tackle the larger issue for 10.1.1
> Features and plugins for Fuse tooling have various versions
> -----------------------------------------------------------
>
> Key: JBTIS-1023
> URL: https://issues.jboss.org/browse/JBTIS-1023
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: build, distribution
> Affects Versions: 10.1.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Lars Heinemann
> Priority: Blocker
>
> |org.fusesource.ide.camel.editor.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.core.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.jmx.feature|9.1.0.CR1-v20170103-1319-B91|
> |org.fusesource.ide.server.extensions.feature|9.1.0.CR1-v20170105-1331-B91|
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBTIS-1023) Features and plugins for Fuse tooling have various versions
by Andrej Podhradsky (JIRA)
[ https://issues.jboss.org/browse/JBTIS-1023?page=com.atlassian.jira.plugin... ]
Andrej Podhradsky commented on JBTIS-1023:
------------------------------------------
For QE it doesn't matter which format is used, the most important thing is to have the same format for all components (such as fuse, switchyard, ...) and the same version of features in one component (such as org.fusesource.ide.core.feature, org.fusesource.ide.jmx.feature in the fuse component).
> Features and plugins for Fuse tooling have various versions
> -----------------------------------------------------------
>
> Key: JBTIS-1023
> URL: https://issues.jboss.org/browse/JBTIS-1023
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: build, distribution
> Affects Versions: 10.1.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Lars Heinemann
> Priority: Blocker
>
> |org.fusesource.ide.camel.editor.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.core.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.jmx.feature|9.1.0.CR1-v20170103-1319-B91|
> |org.fusesource.ide.server.extensions.feature|9.1.0.CR1-v20170105-1331-B91|
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBTIS-1023) Features and plugins for Fuse tooling have various versions
by Aurélien Pupier (JIRA)
[ https://issues.jboss.org/browse/JBTIS-1023?page=com.atlassian.jira.plugin... ]
Aurélien Pupier commented on JBTIS-1023:
----------------------------------------
{quote}
Rather than reverting parent pom version (and getting an old target platform) you can simply override the timestamp provider you use.
{quote}
we are not getting an old target platform by using the old paren tpom as we are using the JBTIS Target Platform which is managed by a different version.
Seems that changing the format without the build number is causing issue to QE, I would prefer to keep it for the upcoming as we are in CR phase.
We need to rediscuss with QE if we can change the format for next release and what it implies for them.
> Features and plugins for Fuse tooling have various versions
> -----------------------------------------------------------
>
> Key: JBTIS-1023
> URL: https://issues.jboss.org/browse/JBTIS-1023
> Project: JBoss Tools Integration Stack
> Issue Type: Bug
> Components: build, distribution
> Affects Versions: 10.1.0.CR1
> Reporter: Andrej Podhradsky
> Assignee: Lars Heinemann
> Priority: Blocker
>
> |org.fusesource.ide.camel.editor.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.core.feature|9.1.0.CR1-v20170120-1811-B91|
> |org.fusesource.ide.jmx.feature|9.1.0.CR1-v20170103-1319-B91|
> |org.fusesource.ide.server.extensions.feature|9.1.0.CR1-v20170105-1331-B91|
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-23811) ZipException in CDICoreBuilder when indexing some Maven artifacts
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23811?page=com.atlassian.jira.plugi... ]
Jeff MAURY updated JBIDE-23811:
-------------------------------
Fix Version/s: 4.4.3.Final
> ZipException in CDICoreBuilder when indexing some Maven artifacts
> -----------------------------------------------------------------
>
> Key: JBIDE-23811
> URL: https://issues.jboss.org/browse/JBIDE-23811
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: cdi
> Reporter: Aurélien Pupier
> Assignee: Jeff MAURY
> Fix For: 4.4.3.Final
>
>
> it would be nice to provide more information in log such as the classes in inspection by CDI Core Builder.
> Also if there are some issues with those jars, please report bugs to them.
> {noformat}
> !ENTRY org.jboss.tools.common.core 4 0 2017-01-17 11:17:20.815
> !MESSAGE invalid LOC header (bad signature)
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(ZipFile.java:60)
> at java.util.zip.ZipFile$ZipFileInputStream.read(ZipFile.java:717)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(ZipFile.java:419)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read1(BufferedInputStream.java:286)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
> at java.io.DataInputStream.readFully(DataInputStream.java:195)
> at java.io.DataInputStream.readFully(DataInputStream.java:169)
> at org.jboss.jandex.Indexer.verifyMagic(Indexer.java:433)
> at org.jboss.jandex.Indexer.index(Indexer.java:689)
> at org.jboss.tools.common.core.jandex.JandexUtil.createJarIndex(JandexUtil.java:56)
> at org.jboss.tools.common.core.jandex.JandexUtil.hasAnnotation(JandexUtil.java:104)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.hasAnnotatedBeans(BeanArchiveDetector.java:276)
> at org.jboss.tools.cdi.internal.core.scanner.lib.BeanArchiveDetector.resolve(BeanArchiveDetector.java:203)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.detectBeanModule(ClassPathMonitor.java:150)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:106)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
> {noformat}
> !ENTRY org.jboss.tools.common.model 4 0 2017-01-25 16:11:53.722
> !MESSAGE Exception occurs when reading C:\Users\Aurelien Pupier\.m2\repository\org\apache\aries\blueprint\org.apache.aries.blueprint.core\1.7.1\org.apache.aries.blueprint.core-1.7.1.jar
> !STACK 0
> java.util.zip.ZipException: invalid LOC header (bad signature)
> at java.util.zip.ZipFile.read(Native Method)
> at java.util.zip.ZipFile.access$1400(Unknown Source)
> at java.util.zip.ZipFile$ZipFileInputStream.read(Unknown Source)
> at java.util.zip.ZipFile$ZipFileInflaterInputStream.fill(Unknown Source)
> at java.util.zip.InflaterInputStream.read(Unknown Source)
> at java.io.BufferedInputStream.fill(Unknown Source)
> at java.io.BufferedInputStream.read1(Unknown Source)
> at java.io.BufferedInputStream.read(Unknown Source)
> at org.jboss.tools.common.model.filesystems.impl.JarAccess.getContent(JarAccess.java:235)
> at org.jboss.tools.common.model.filesystems.impl.JarAccess.isTextEntry(JarAccess.java:266)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.createFileObject(JarFolderImpl.java:95)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.loadChildren(JarFolderImpl.java:78)
> at org.jboss.tools.common.model.impl.RegularObjectImpl.getChildByPathPart(RegularObjectImpl.java:159)
> at org.jboss.tools.common.model.filesystems.impl.JarFolderImpl.getChildByPathPart(JarFolderImpl.java:152)
> at org.jboss.tools.common.model.impl.XModelObjectImpl.getChildByPath(XModelObjectImpl.java:347)
> at org.jboss.tools.common.model.impl.XModelObjectImpl.getChildByPath(XModelObjectImpl.java:352)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.readRuntimes(ClassPathMonitor.java:286)
> at org.jboss.tools.cdi.internal.core.scanner.lib.ClassPathMonitor.process(ClassPathMonitor.java:103)
> at org.jboss.tools.cdi.core.CDICoreBuilder.build(CDICoreBuilder.java:215)
> at org.jboss.tools.cdi.core.CDICoreBuilder.<init>(CDICoreBuilder.java:101)
> at org.jboss.tools.cdi.core.CDICoreNature.load(CDICoreNature.java:420)
> at org.jboss.tools.cdi.core.CDICoreNature.resolveStorage(CDICoreNature.java:393)
> at org.jboss.tools.cdi.core.CDICoreNature.resolve(CDICoreNature.java:406)
> at org.jboss.tools.cdi.core.CDICorePlugin.getCDI(CDICorePlugin.java:165)
> at org.jboss.tools.cdi.core.CDICorePlugin$RCL.resourceChanged(CDICorePlugin.java:104)
> at org.eclipse.core.internal.events.NotificationManager$1.run(NotificationManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:289)
> at org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:152)
> at org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:374)
> at org.eclipse.core.internal.resources.Workspace.endOperation(Workspace.java:1469)
> at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:46)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months
[JBoss JIRA] (JBIDE-23733) Merge .smoke and .nightly integration jobs into a single job and run them weekly
by Rastislav Wagner (JIRA)
[ https://issues.jboss.org/browse/JBIDE-23733?page=com.atlassian.jira.plugi... ]
Rastislav Wagner commented on JBIDE-23733:
------------------------------------------
[~nickboldt] Good idea. Is it possible to define list of jobs to run using regex in flow DSL ? Or do we just name them all in something like
{code:java}
parallel {( build(job1) .... )}
{code}
I couldnt find any info about using regex so I guess it is not possible ?
[~rob.stryker] yes we will get rid of jbt-integration-tests repo but it is still better to keep the integration jobs *which runs against devstudio (& are managed by QE)* separate due to reasons I mentioned above.
> Merge .smoke and .nightly integration jobs into a single job and run them weekly
> --------------------------------------------------------------------------------
>
> Key: JBIDE-23733
> URL: https://issues.jboss.org/browse/JBIDE-23733
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, integration-tests
> Affects Versions: 4.4.3.AM1
> Reporter: Nick Boldt
> Assignee: Rastislav Wagner
> Fix For: 4.4.3.Final
>
>
> Purpose:
> a) easier maintenance of jobs / tests
> b) run fewer nightly jobs so that we don't block slaves from being available for other builds / tests
> c) more frequent full integration runs (rather than once per sprint, once per week)
> Tests to merge are in this view:
> https://dev-platform-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/Devstud...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 8 months