[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=12810666#comment-12810666 ] 

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

CI = continuous integration. These are CI builds. "CI builds are normally staged eventually but not directly from CI ?" << No idea what you're asking.

*Re: need for name change: * The addition of the /CI/ path segment *for all builds using the new publish script* was an arbitrary change, simply done to differentiate them from the older staging/staging.previous builds. It *is* being done uniformly - all a project needs to do is adopt the new publish script and they'll start publishing to the new location scheme.

Making this distinction makes it easier to see which builds are being built the new way vs. which are built the old way (eg., the ongoing SOA Tooling 5.x builds).


                
> 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