[jbosstools-issues] [JBoss JIRA] (JBIDE-11524) Rename jobs, sites, profiles, variables... to clearer names (remove reference to nightly)

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-11524 at 4/16/12 10:13 AM:
--------------------------------------------------------------

Renaming stuff doesn't guarantee it won't still be seen as black magic. But conceptually I agree we want to make this simpler.

So, I see a number of use cases:

{code}
a) build against local sources                             (mvn install -f build/pom.xml -Pfoo-bootstrap)
b) build against binaries; upstream staging composite site (mvn install -Pstaging) [also the mode that Jenkins needs for Core]
c) build against binaries; upstream nightly aggregate site (mvn install -Pnightly) [also the mode that Jenkins needs for SOA]
d) build against binaries; upstream dev milestone agg site (mvn install)           [average user?]
e) build against binaries; upstream previous release       (mvn install -Prelease) [?]
{code}

Are we assuming that there should be two modes for suffixes too? eg., for CI builds we use the usual vTIMESTAMP-Hxxx-SUFFIX, but for releases we use something different?

I don't understand what you mean by "The content of nightly/snapshot is then committed proper versioned parent pom's in the branches/trunk." Are you suggesting that every time we spin a nightly aggregate we commit a change to the parent pom in SVN?

As to the comment "each branch has the same commands to use", that's currently true (I've even backported naming convention changes to the 3.2.x branch from the 3.3.x one) but if you start creating new profiles and renaming variables, you'll end up with a new set of commands in 3.3 vs. 3.2.x. 

However, we could get to a point where -Pnightly if run in trunk would point at a different set of upstream sites than -Pnightly from the latest stable branch (ie., after branching for Beta3). In fact that's how things work today (though using longer profile names).

To continue to achieve this "smart profile" functionality, however, we either need to change all the root poms every time we branch to point a new version of the parent pom in Nexus (eg., parent pom version 3.3.0.Beta1 vs. parent pom version 3.3.0.trunk), or rebuild it locally every time as part of each job in Jenkins (as we do for 3.2.x and did for 3.3.0.Beta1 & Beta2). This will ensure that the local version from the correct branch is used instead of the problem we have now where BOTH trunk and the forthcoming Beta3 branch COULD see the same version of the parent pom (0.0.4-SNAPSHOT) in nexus and get the wrong variables (URLs, suffixes).



                
      was (Author: nickboldt):
    Renaming stuff doesn't guarantee it won't still be seen as black magic. But conceptually I agree we want to make this simpler.

So, I see a number of use cases:

{code}
a) build against local sources (mvn install -f build/pom.xml -Pfoo-bootstrap)
b) build against binaries; upstream staging composite site (mvn install -Pstaging) [also the mode that Jenkins needs for Core]
c) build against binaries; upstream nightly aggregate site (mvn install -Pnightly) [also the mode that Jenkins needs for SOA]
d) build against binaries; upstream dev milestone agg site (mvn install)           [average user?]
e) build against binaries; upstream previous release       (mvn install -Prelease) [?]
{code}

Are we assuming that there should be two modes for suffixes too? eg., for CI builds we use the usual vTIMESTAMP-Hxxx-SUFFIX, but for releases we use something different?

I don't understand what you mean by "The content of nightly/snapshot is then committed proper versioned parent pom's in the branches/trunk." Are you suggesting that every time we spin a nightly aggregate we commit a change to the parent pom in SVN?

As to the comment "each branch has the same commands to use", that's currently true (I've even backported naming convention changes to the 3.2.x branch from the 3.3.x one) but if you start creating new profiles and renaming variables, you'll end up with a new set of commands in 3.3 vs. 3.2.x. 

However, we could get to a point where -Pnightly if run in trunk would point at a different set of upstream sites than -Pnightly from the latest stable branch (ie., after branching for Beta3). In fact that's how things work today (though using longer profile names).

To continue to achieve this "smart profile" functionality, however, we either need to change all the root poms every time we branch to point a new version of the parent pom in Nexus (eg., parent pom version 3.3.0.Beta1 vs. parent pom version 3.3.0.trunk), or rebuild it locally every time as part of each job in Jenkins (as we do for 3.2.x and did for 3.3.0.Beta1 & Beta2). This will ensure that the local version from the correct branch is used instead of the problem we have now where BOTH trunk and the forthcoming Beta3 branch COULD see the same version of the parent pom (0.0.4-SNAPSHOT) in nexus and get the wrong variables (URLs, suffixes).



                  
> Rename jobs, sites, profiles, variables... to clearer names (remove reference to nightly)
> -----------------------------------------------------------------------------------------
>
>                 Key: JBIDE-11524
>                 URL: https://issues.jboss.org/browse/JBIDE-11524
>             Project: Tools (JBoss Tools)
>          Issue Type: Enhancement
>          Components: Build/Releng
>            Reporter: Mickael Istria
>            Assignee: Nick Boldt
>            Priority: Minor
>
> nightly is a very confusing name, that does not reflect at all what really happens.
> We should prefer using "staging" in variable, profiles, jobs, url... to make it clearer
> For instance,
> * jbosstools-nightly-staging-composite -> jbosstools-staging-composite
> * jboostools-nightly -> jbosstools-staging-aggregate

--
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