[jbosstools-issues] [JBoss JIRA] (JBIDE-11639) Remove patterns starts from "**/" from hudson configuration for JBoss Tools build projects

Denis Golovin (JIRA) jira-events at lists.jboss.org
Tue Apr 24 20:21:17 EDT 2012


     [ https://issues.jboss.org/browse/JBIDE-11639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Denis Golovin updated JBIDE-11639:
----------------------------------

    Description: 
Once I removed all patterns like 

{code}"**/TESTS-*.xml"{code}

from all JBT related builds from trunk but they keeps coming back.

Such patterns for searching files in emma code coverage publishing, JUnit reports gathering or anywhere else in hudson project configuartion are evil because it slows down builds. After each build hudson should iterate overs everything in workspace (sources, build results, local maven repo) to find (in example above) JUnit test results. It should be something like

{code}sources/tests/*/target/surefire-reports/TEST*.xml{code}

which is much faster comparing to one uses "**" pattern.

The same for code coverage xml. Instead of putting something like

{code}**/coverage.xml{code}

to find just one file in whole workspace use just direct path to this file

it saves from couple to tens minutes for component build and if we look at build numbers HXXXX it becomes huge waste of time






  was:
Once I removed all patterns like 

{code}"**/TESTS-*.xml"{code}

from all JBT related builds from trunk but they keep coming back.

Such patterns for searching files in emma code coverage publishing, JUnit reports gathering or anywhere else in hudson project configuartion are evil because it slows down builds. After each build hudson should iterate overs everything in workspace (sources, build results, local maven repo) to find (in example above) JUnit test results. It should be something like

{code}sources/tests/*/target/surefire-reports/TEST*.xml{code}

which is much faster comparing to one uses "**" pattern.

The same for code coverage xml. Instead of putting something like

{code}**/coverage.xml{code}

to find just one file in whole workspace use just direct path to this file

it saves from couple to tens minutes for component build and if we look at build numbers HXXXX it becomes huge waste of time







    
> Remove patterns starts from "**/" from hudson configuration for JBoss Tools build projects
> ------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-11639
>                 URL: https://issues.jboss.org/browse/JBIDE-11639
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: Build/Releng
>    Affects Versions: 3.3.0.Beta3
>            Reporter: Denis Golovin
>            Assignee: Nick Boldt
>            Priority: Critical
>             Fix For: 3.3.0.Beta3
>
>
> Once I removed all patterns like 
> {code}"**/TESTS-*.xml"{code}
> from all JBT related builds from trunk but they keeps coming back.
> Such patterns for searching files in emma code coverage publishing, JUnit reports gathering or anywhere else in hudson project configuartion are evil because it slows down builds. After each build hudson should iterate overs everything in workspace (sources, build results, local maven repo) to find (in example above) JUnit test results. It should be something like
> {code}sources/tests/*/target/surefire-reports/TEST*.xml{code}
> which is much faster comparing to one uses "**" pattern.
> The same for code coverage xml. Instead of putting something like
> {code}**/coverage.xml{code}
> to find just one file in whole workspace use just direct path to this file
> it saves from couple to tens minutes for component build and if we look at build numbers HXXXX it becomes huge waste of time

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


More information about the jbosstools-issues mailing list