[jbosstools-issues] [JBoss JIRA] (JBDS-3208) reorg/refactor directories for consistency across JBT/JBDS

Nick Boldt (JIRA) issues at jboss.org
Mon Dec 1 16:10:39 EST 2014


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

Nick Boldt commented on JBDS-3208:
----------------------------------

Max: You've said repeatedly that you want *nightly* (or *snapshots*, if people approve my/Mickael's renaming scheme above) to be a composite. You've also said the reason for this is so that nightly builds don't disappear while new ones are being published to the same URL [as happens for /nightly/core/4.2.luna and /nightly/core/master/). This rationale makes sense. 

The secondary issue of providing a stable URL for nightly builds which can point to either master or the 4.2.x branch [the step we forgot to do after we branched for jbosstools-4.2.x] has nothing to do with a reorg/refactoring of the URLs above. We still need that symlink, and we need to remember to move it to point to the correct content after we branch for 4.N.x every year.



> reorg/refactor directories for consistency across JBT/JBDS
> ----------------------------------------------------------
>
>                 Key: JBDS-3208
>                 URL: https://issues.jboss.org/browse/JBDS-3208
>             Project: Developer Studio (JBoss Developer Studio)
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 9.0.0.Alpha1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 9.0.0.Alpha1
>
>
> Be it resolved - we should reorg directories for consistency across JBT/JBDS:
> {code}
>     download.jboss.org
>     <earlyaccess,updates,discovery>/mars
>        /snapshots [replace nightly]
>        /staging [rename content for QE, moves to development when approved]
>        /development
>        /stable (updates/mars/stable is a pointer back into updates/mars)
>       drop /integration (not used)
>     builds/<jobname>/<buildid>
>     builds/<jobname>/composite*.xml for last 2 builds
>     targetplatforms/<type>/<version>
> {code}
>     and
> {code}
>     devstudio.redhat.com
>     <earlyaccess,updates,discovery>/9.0
>        /snapshots
>        /staging
>        /development
>        /stable (updates/9.0/stable is a pointer back into updates/9.0)
>     builds/<jobname>/<buildid>
>     builds/<jobname>/composite*.xml for last 2 builds
>     targetplatforms/<type>/<version>
> {code}
> Further discussion in http://ether-man.rhcloud.com/p/build.next.20141112
> This would remove the idea of the composite staging site [1] and the composite install job [2], today used to determine when  it's time to run the aggregate builds, in favour of a new p2diff mechanism for determining if aggregates should be published. See JBIDE-18742 and JBIDE-16970. 
> [1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.2.luna/
> [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevStudio_8.0.luna/job/jbosstools-composite-install_4.2.luna/



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)


More information about the jbosstools-issues mailing list