[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-8667) improve publishing of component sites using composite metadata so that content doesn't vanish and break downstream jobs

[Nick Boldt (JIRA)]

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

Nick Boldt commented on JBIDE-8667:
-----------------------------------

Max said:
> I was wondering if we got a page somewhere (if not we should create one) that just outlines the various sites there are in play and what triggers their update and how often they get updated, what stays for how long.

Currently there's the cascade page [0], but I don't mention the staging.previous [1] folder which now provides the "last build before the current one" alluded to above.

Both the staging [2] and staging.previous [1] are now composited together here [3], so that an aggregate site [4] can be built & published [5].

[0] http://download.jboss.org/jbosstools/builds/cascade/trunk.html
[1] http://download.jboss.org/jbosstools/builds/staging.previous/
[2] http://download.jboss.org/jbosstools/builds/staging/
[3] http://download.jboss.org/jbosstools/builds/staging/_composite_/trunk/
[4] http://hudson.qa.jboss.com/hudson/job/jbosstools-3.3_trunk.aggregate/
[5] http://download.jboss.org/jbosstools/updates/nightly/trunk/

Both staging and staging.previous are updated every time a new CI nightly spins and publishes its results. Commit a change to SVN, a build will run, and the sites will be updated.

> improve publishing of component sites using composite metadata so that content doesn't vanish and break downstream jobs
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBIDE-8667
>                 URL: https://issues.jboss.org/browse/JBIDE-8667
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: Build/Releng
>    Affects Versions: 3.3.0.M1
>            Reporter: Nick Boldt
>            Assignee: Nick Boldt
>             Fix For: 3.3.0.M3
>
>
> (2011-04-01 10:11:04) nickboldt: and while I'd love to do:
> (2011-04-01 10:11:12) nickboldt: mkdir whatever-new
> (2011-04-01 10:11:22) nickboldt: rsync newstuff whatever-new
> (2011-04-01 10:11:25) nickboldt: rm -fr whatever
> (2011-04-01 10:11:29) nickboldt: mv whatever-new whatever
> (2011-04-01 10:11:43) nickboldt: so that the time between "it's there" and "it's there and updated" is less
> (2011-04-01 10:11:52) nickboldt: I CANNOT with the current infra we have
> (2011-04-01 10:12:03) nickboldt: instead I can do an rsync --delete and push into the same folder on top
> (2011-04-01 10:12:16) nickboldt: but that means that the metadata will oft be out of whack w.r.t the site content
> (2011-04-01 10:12:17) maxandersen: hmmm
> (2011-04-01 10:12:41) nickboldt: if you can think of a way to do a "push then rename" instead of "push into existing and clean out cruft"
> (2011-04-01 10:12:51) nickboldt: over sftp via a script (non-interactive) then I'm all ears
> (2011-04-01 10:13:26) nickboldt: I can't push a script there and run it, or simply connect over ssh and run a script directly
> (2011-04-01 10:13:35) maxandersen: well what I was thinking was to do a push of new site into new dir, push site.xml/compositewhatever pointing to new dir and then rsync delete the existing one..
> (2011-04-01 10:14:10) maxandersen: sftp rm should work?
> (2011-04-01 10:14:13) nickboldt: MIGHT be able to do sftp delete
> (2011-04-01 10:14:39) maxandersen: if you control it with a composite artifact you dont need to rename anything
> (2011-04-01 10:14:51) maxandersen: except the content pointer in there which you know "locally"
> (2011-04-01 10:15:01) nickboldt: true... so I'd need a tool to do a one line swap in the composite*.xml files
> (2011-04-01 10:15:13) nickboldt: remove ref to old site, replace w/ ref to new site
> (2011-04-01 10:15:17) nickboldt: and then delete the old one
> 1. generate composite metadata files on the fly
> 2. publish that into root dir, all/repo/
> 3. purge previous build's folder over scripted sftp?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira