[jbosstools-issues] [JBoss JIRA] (JBIDE-15483) generate content in staging/_composite_/core/{trunk, 4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}

[Nick Boldt (JIRA)]

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

Nick Boldt edited comment on JBIDE-15483 at 9/25/13 1:06 PM:
-------------------------------------------------------------

With the above script enabled in the composite site install job [1] I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publish.sh (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publish_new.sh (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}

[1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/ >=4903 *{color:red}AWAITING FREE SLAVE{color}* 

Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and deprecate the old approach.

THEN I can consider rolling this out to the 4.1.x branch for Beta2.
                
      was (Author: nickboldt):
    With the above script enabled in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/ I can now start switching all the _master jobs to use the new publish_new.sh script, as per JBIDE-14482:
{quote}
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publish.sh (old way, JOB_NAME/all/repo/)
https://raw.github.com/jbosstools/jbosstools-build-ci/master/publish/publish_new.sh (new way, JOB_NAME/BUILD_ID/all/repo/)
{quote}

Then we'll need to update the parent pom to point at http://download.jboss.org/jbosstools/builds/staging/_composite_/core/master instead of http://download.jboss.org/jbosstools/builds/staging/_composite_/core/trunk, and we can effectively deprecate the old builds. 

THEN I can consider rolling this out to the 4.1.x branch for Beta2.
                  
> generate content in staging/_composite_/core/{trunk,4.1.kepler} based on new builds/staging/{JOB_NAME}/{BUILD_ID_N} and builds/staging/{JOB_NAME}/{BUILD_ID_N-1}
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-15483
>                 URL: https://issues.jboss.org/browse/JBIDE-15483
>             Project: Tools (JBoss Tools)
>          Issue Type: Sub-task
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.1.1.Beta1, 4.2.0.Alpha1
>
>
> Because the content in builds/staging/\{JOB_NAME}/all/repo/ and builds/staging.previous/\{JOB_NAME}/all/repo/ is moving to builds/staging/\{JOB_NAME}/\{BUILD_ID_N} and builds/staging/\{JOB_NAME}/\{BUILD_ID_N-1}, we need to generate a list of matching build URLs for inclusion in the composite*.xml files, perhaps based on a template that's stored in github (to define which projects to include).
> Parameters to the generation would need to be:
> a) template
> b) number of builds per project to include (1, for stable_branch or 2, for trunk)
> Constraints:
> * Need to ensure that the generated files are always fresher than anything pulled from github via rsync, so templates should not be called "compositeContent.xml" but rather "compositeContent.template.xml"
> * Need to be able to run this regeneration as a Jenkins job, perhaps as the first step in https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_41/ and https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-composite-install_master/
> Worries:
> * What happens if the regen happens and then a jbosstools-cleanup.sh fires minutes later, wiping out that N-1 build? Does jbosstools-cleaup.sh need to regen these files too?
> Default operation of jbosstools-cleanup.sh as called from publish_new.sh and publish.sh is to keep the last 5 builds and anything newer than 5 days old; if there are no such builds, it will always keep the last build in a folder:
> {code}./jbosstools-cleanup.sh --keep 5 --age-to-delete 5 --childFolderSuffix /all/repo/{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