[jbosstools-issues] [JBoss JIRA] (JBIDE-20394) jbosstools integration tests site depends on itself to build; site is not self-cleaning

[Nick Boldt (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-20394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093468#comment-13093468 ] 

Nick Boldt commented on JBIDE-20394:
------------------------------------

Re: #1, the alternative solution is to build the whole project locally, THEN just run the test you want. But I suppose that's equivalent to resolving deps from the latest nightly, too. 

How about if we have a *jbosstools-integrationtests-site* profile for this, which is enabled by default, but when run in Jenkins we disable it so that it's ONLY using local sources to resolve deps instead of this "self-bootstrapped" approach?  Thus in Jenkins:

{code}mvn install -P!jbosstools-integrationtests-site{code}

Does that work for a profile name? We could call it "bootstrap" "nightly" "circular" ... 

Or we could use the "hudson" profile (already in use in parent pom for other purposes) to set $\{jbosstools-integrationtests-site} to $\{jbosstools-site} so that it's effectively disabled.

> jbosstools integration tests site depends on itself to build; site is not self-cleaning
> ---------------------------------------------------------------------------------------
>
>                 Key: JBIDE-20394
>                 URL: https://issues.jboss.org/browse/JBIDE-20394
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: build, integration-platform
>    Affects Versions: 4.3.0.Beta2
>            Reporter: Nick Boldt
>            Assignee: Martin Malina
>             Fix For: 4.3.0.Beta2, 4.3.0.CR1
>
>
> I've found some problems today:
> 1. building JBT integration tests requires the JBT integration tests site [circular dependency]
> {code}
>  [INFO] Adding repository http://download.jboss.org/jbosstools/updates/nightly/integrationtests/4.3.mars 
> {code}
> 2. nightly 4.3.mars site [0] contains both Beta2 and CR1 bits, even though it's just the 4.3.mars site and should therefore only have Beta2 bits (CR1 should only be in master site [1]
> [0] http://download.jboss.org/jbosstools/updates/nightly/integrationtests/4.3.mars/
> [1] http://download.jboss.org/jbosstools/updates/nightly/integrationtests/master/
> 3. each time a new build is published into /updates/ [2], [3] it does NOT clean out the old releases, so the site is unnecessarily cluttered with old, orphan artifacts.
> [2] http://download.jboss.org/jbosstools/mars/snapshots/updates/integration-tests/4.3.mars/
> [3] http://download.jboss.org/jbosstools/mars/snapshots/updates/integration-tests/master/
> 4. The above sites [2], [3] contain content from BOTH branches, which is why we have artifacts from B440 (master) and B25 (4.3.mars) at the same time.
> 5. The check that the build does to determine if it should publish the new bits is failing to find the check script.
> 6. There are two different URLs [0], [2] being used for publishing bits, but the contents appear to be identical.
> [0] http://download.jboss.org/jbosstools/mars/snapshots/updates/integration-tests/4.3.mars/
> [2] http://download.jboss.org/jbosstools/updates/nightly/integrationtests/4.3.mars/
> This is because we have symlinks:
> {code}
> updates/nightly/integrationtests/4.3.mars -> ../../../mars/snapshots/updates/integration-tests/4.3.mars/
> updates/nightly/integrationtests/master -> ../../../mars/snapshots/updates/integration-tests/master/
> {code}
> So this is OK but we should migrate to use the new correct URLs instead of the old ones.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)