[jbosstools-issues] [JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBIDE-15482:
------------------------------------

[~maxandersen] The idea behind the URL pattern change was so that the automated cleanup would only apply to the NEW builds, not the old ones. So staging/CI/ is a folder under which automated cleanup occurs, but staging/ is not. This is to prevent data loss and screw up any JBDS SOA 5.x builds which will not migrate to the new scheme. 

And since everyone should be building based on the composite sites [1], [2], not the individual components' staging sites, this is an internal detail that shouldn't affect anyone anyway. 

[1] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.kepler/ with human-managed children (publish.sh, old way)
[2] http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.x.kepler/ with script-generated children (publish_new.sh, new way)

IMHO, it **IS** necessary and doesn't hurt anything. What's the concern here? Change might be scary sometimes, but evolution requires it.

[~mmalina] As to putting in a readme, sure, we could, but isn't the fact that there's a nested <build#> folder enough to make it obvious we're using the newer publish_new.sh instead of the old one?

[~mickael_istria] Are you really suggesting we use http://download.jboss.org/jbosstools/builds/staging/<jobName>/all/repo/<jobName>/<build#>/all/repo ? that's longer and more redundant than just using builds/staging/CI/<jobName><build#>/all/repo/ ... and since builds/staging/CI/<jobName> is **already** a composite of the child builds, we already have a static URL for "latest build of a given component's job for a given stream".



                
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-15482
>                 URL: https://issues.jboss.org/browse/JBIDE-15482
>             Project: Tools (JBoss Tools)
>          Issue Type: Task
>          Components: build, updatesite
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 4.1.1.Alpha2
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after 
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and 
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}

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