Everyone: I've generalized the script I gave SwitchYard for promoting their nightlies to development (or stable) so it's much easier to "release" code to the community. Now with a handful of job parameters, you can publish your latest nightly on demand as a new build type. (Aside: you may find I use the terms "promote" or "publish" interchangeably. That's because the act of "publishing" may include the act of renaming or "promoting" a build from a lower status (nightly/snapshot) to a higher status (milestone/release). Similarly, "promoting" may include the act of "publishing" bits from within Jenkins (lower state, internal only) to download.jboss.org (higher state, publicly available). Apologies in advance for the confusion this may cause.) Anyhoo... the new script is here [0]. To use this in your own job, simply copy one of the jobs [1], [2] mentioned below, and you can publish your bits into the standard JBoss Tools directory structure. --- Rob, Your SwitchYard-Tools-publish job [1] has been updated and should work but I haven't run it because I don't want to actually release one of your nightlies as a dev milestone. Note too that the order of the options for which Eclipse platform to use in the published path has been reversed as I assume you're now building on Juno, not Indigo (with possible backward support for Indigo). If that's an incorrect assumption it's easy to revert the options' order in the job config. --- Dan & Randall, I've tested this new script with ModeShape-Tools, and published [2] your latest nightly [3] as 3.0.0.Beta5, since that's what Dan was trying to do earlier today before he contacted me. Here are the jobs [2], [3]. Here's the build promoted by the -publish job [4]. If you weren't ready to call it a milestone we can delete it and respin as needed -- or just republish on top! Note too that I moved your older Beta1 release from its old place under /modeshape/tools/updates/develop/ to here for consistency [5]. You might want to delete it entirely as it uses the old x.y.z.vTIMESTAMP versioning scheme which can't be updated to the new x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules (users must uninstall it first). Oh, and I noticed that your Beta1 was targetted at Indigo, but I assume your Beta5 is targetted at Juno. Is that correct? --- SOA/BRMS project leads, I've also created a new view in Jenkins to collate all the trunk/JBT4/JBDS6 jobs into a single place: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... If your job(s) aren't listed, please edit the view and add them. Once it's complete I can spawn a duplicate view (excluding the JBDS job(s)) which we can push to the public-facing Jenkins server, similar to http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/ Why? Because community! --- Still to do: a) generate composite site metadata for all the contributed projects in a given folder so that end users can simply look to one URL instead of several (JBIDE-12662) - eg., http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/ or http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/ b) generate index.html pages for the sites in place of a bare directory listing - requires adding an option to feed in a different header graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects have their own branding already - see [5]). Then it's a simple matter of adapting what's already done for Central [6]. --- Refs: [0] http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... [2] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... [3] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... (publishes to builds/staging/${JOB_NAME}) [4] http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... [5] http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... [6] http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

Forgot one of the script parameters in the job. Fixed. https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... As to not using it correctly, you COULD use 0.6.0.Beta1, 0.6.0.Beta2, 0.6.0.CR1, and then 0.6.0.Final (in stable folder, not development). This is how we track iterations of milestones for the JBT and JBDS aggregate builds. But your way means less manual cleanup and no need for symlinking a "latest" folder. With your way, each subsequent publish simply overwrites the previous. (This is a problem for anyone trying to use the site while the push is happening as files are busy appearing and disappearing, but after that it's a fine approach.)

Nick On 09/21/2012 05:30 PM, Rob Cernich wrote: > Hey Nick, > > Thanks for putting this together and thanks for updating the > SwitchYard publish job. That said, I don't think I'm using it > correctly. Any advice would be greatly appreciated. > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... > > Thanks in advance, > Rob > > ----- Original Message ----- >> Everyone: >> >> I've generalized the script I gave SwitchYard for promoting their >> nightlies to development (or stable) so it's much easier to >> "release" >> code to the community. Now with a handful of job parameters, you >> can >> publish your latest nightly on demand as a new build type. >> >> (Aside: you may find I use the terms "promote" or "publish" >> interchangeably. That's because the act of "publishing" may >> include >> the >> act of renaming or "promoting" a build from a lower status >> (nightly/snapshot) to a higher status (milestone/release). >> Similarly, >> "promoting" may include the act of "publishing" bits from within >> Jenkins >> (lower state, internal only) to download.jboss.org (higher state, >> publicly available). Apologies in advance for the confusion this >> may >> cause.) >> >> Anyhoo... the new script is here [0]. >> >> To use this in your own job, simply copy one of the jobs [1], [2] >> mentioned below, and you can publish your bits into the standard >> JBoss >> Tools directory structure. >> >> --- >> >> Rob, >> >> Your SwitchYard-Tools-publish job [1] has been updated and should >> work >> but I haven't run it because I don't want to actually release one >> of >> your nightlies as a dev milestone. Note too that the order of the >> options for which Eclipse platform to use in the published path >> has >> been >> reversed as I assume you're now building on Juno, not Indigo (with >> possible backward support for Indigo). If that's an incorrect >> assumption >> it's easy to revert the options' order in the job config. >> >> --- >> >> Dan & Randall, >> >> I've tested this new script with ModeShape-Tools, and published >> [2] >> your >> latest nightly [3] as 3.0.0.Beta5, since that's what Dan was >> trying >> to >> do earlier today before he contacted me. Here are the jobs [2], >> [3]. >> >> Here's the build promoted by the -publish job [4]. If you weren't >> ready >> to call it a milestone we can delete it and respin as needed -- or >> just >> republish on top! >> >> Note too that I moved your older Beta1 release from its old place >> under >> /modeshape/tools/updates/develop/ to here for consistency [5]. You >> might >> want to delete it entirely as it uses the old x.y.z.vTIMESTAMP >> versioning scheme which can't be updated to the new >> x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules >> (users >> must uninstall it first). >> >> Oh, and I noticed that your Beta1 was targetted at Indigo, but I >> assume >> your Beta5 is targetted at Juno. Is that correct? >> >> --- >> >> SOA/BRMS project leads, >> >> I've also created a new view in Jenkins to collate all the >> trunk/JBT4/JBDS6 jobs into a single place: >> >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >> >> If your job(s) aren't listed, please edit the view and add them. >> >> Once it's complete I can spawn a duplicate view (excluding the >> JBDS >> job(s)) which we can push to the public-facing Jenkins server, >> similar >> to http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/ >> >> Why? Because community! >> >> --- >> >> Still to do: >> >> a) generate composite site metadata for all the contributed >> projects >> in >> a given folder so that end users can simply look to one URL >> instead >> of >> several (JBIDE-12662) - eg., >> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/ >> or >> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/ >> >> b) generate index.html pages for the sites in place of a bare >> directory >> listing - requires adding an option to feed in a different header >> graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects >> have >> their own branding already - see [5]). Then it's a simple matter >> of >> adapting what's already done for Central [6]. >> >> --- >> >> Refs: >> >> [0] >> http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh >> >> [1] >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >> >> [2] >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >> >> >> [3] >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >> (publishes to builds/staging/${JOB_NAME}) >> >> [4] >> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... >> >> [5] >> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... >> >> [6] >> http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> >> >> -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com

Note, we really should not be doing any *overwriting* - only use symbolic links either via filesystem or the composte xml for wiring up the public facing urls to the version specific urls. We have had waay too many "mysterious" disappearance of content in the past to use the overwrite model. /max On 22 Sep 2012, at 02:00, Rob Cernich <rcernich(a)redhat.com&gt; wrote: > Thanks Nick! > > ----- Original Message ----- >> Forgot one of the script parameters in the job. Fixed. >> >> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >> >> As to not using it correctly, you COULD use 0.6.0.Beta1, >> 0.6.0.Beta2, >> 0.6.0.CR1, and then 0.6.0.Final (in stable folder, not >> development). >> This is how we track iterations of milestones for the JBT and JBDS >> aggregate builds. >> >> But your way means less manual cleanup and no need for symlinking >> a >> "latest" folder. With your way, each subsequent publish simply >> overwrites the previous. (This is a problem for anyone trying to >> use >> the >> site while the push is happening as files are busy appearing and >> disappearing, but after that it's a fine approach.) > > Yep, as intended. We will be publishing CR, etc. into stable, > which means we'll only be overwriting if we (I) hork it up. > >> >> Nick >> >> On 09/21/2012 05:30 PM, Rob Cernich wrote: >>> Hey Nick, >>> >>> Thanks for putting this together and thanks for updating the >>> SwitchYard publish job. That said, I don't think I'm using it >>> correctly. Any advice would be greatly appreciated. >>> >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>> >>> Thanks in advance, >>> Rob >>> >>> ----- Original Message ----- >>>> Everyone: >>>> >>>> I've generalized the script I gave SwitchYard for promoting >>>> their >>>> nightlies to development (or stable) so it's much easier to >>>> "release" >>>> code to the community. Now with a handful of job parameters, you >>>> can >>>> publish your latest nightly on demand as a new build type. >>>> >>>> (Aside: you may find I use the terms "promote" or "publish" >>>> interchangeably. That's because the act of "publishing" may >>>> include >>>> the >>>> act of renaming or "promoting" a build from a lower status >>>> (nightly/snapshot) to a higher status (milestone/release). >>>> Similarly, >>>> "promoting" may include the act of "publishing" bits from within >>>> Jenkins >>>> (lower state, internal only) to download.jboss.org (higher >>>> state, >>>> publicly available). Apologies in advance for the confusion this >>>> may >>>> cause.) >>>> >>>> Anyhoo... the new script is here [0]. >>>> >>>> To use this in your own job, simply copy one of the jobs [1], >>>> [2] >>>> mentioned below, and you can publish your bits into the standard >>>> JBoss >>>> Tools directory structure. >>>> >>>> --- >>>> >>>> Rob, >>>> >>>> Your SwitchYard-Tools-publish job [1] has been updated and >>>> should >>>> work >>>> but I haven't run it because I don't want to actually release >>>> one >>>> of >>>> your nightlies as a dev milestone. Note too that the order of >>>> the >>>> options for which Eclipse platform to use in the published path >>>> has >>>> been >>>> reversed as I assume you're now building on Juno, not Indigo >>>> (with >>>> possible backward support for Indigo). If that's an incorrect >>>> assumption >>>> it's easy to revert the options' order in the job config. >>>> >>>> --- >>>> >>>> Dan & Randall, >>>> >>>> I've tested this new script with ModeShape-Tools, and published >>>> [2] >>>> your >>>> latest nightly [3] as 3.0.0.Beta5, since that's what Dan was >>>> trying >>>> to >>>> do earlier today before he contacted me. Here are the jobs [2], >>>> [3]. >>>> >>>> Here's the build promoted by the -publish job [4]. If you >>>> weren't >>>> ready >>>> to call it a milestone we can delete it and respin as needed -- >>>> or >>>> just >>>> republish on top! >>>> >>>> Note too that I moved your older Beta1 release from its old >>>> place >>>> under >>>> /modeshape/tools/updates/develop/ to here for consistency [5]. >>>> You >>>> might >>>> want to delete it entirely as it uses the old x.y.z.vTIMESTAMP >>>> versioning scheme which can't be updated to the new >>>> x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules >>>> (users >>>> must uninstall it first). >>>> >>>> Oh, and I noticed that your Beta1 was targetted at Indigo, but I >>>> assume >>>> your Beta5 is targetted at Juno. Is that correct? >>>> >>>> --- >>>> >>>> SOA/BRMS project leads, >>>> >>>> I've also created a new view in Jenkins to collate all the >>>> trunk/JBT4/JBDS6 jobs into a single place: >>>> >>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>>> >>>> If your job(s) aren't listed, please edit the view and add them. >>>> >>>> Once it's complete I can spawn a duplicate view (excluding the >>>> JBDS >>>> job(s)) which we can push to the public-facing Jenkins server, >>>> similar >>>> to >>>> http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/ >>>> >>>> Why? Because community! >>>> >>>> --- >>>> >>>> Still to do: >>>> >>>> a) generate composite site metadata for all the contributed >>>> projects >>>> in >>>> a given folder so that end users can simply look to one URL >>>> instead >>>> of >>>> several (JBIDE-12662) - eg., >>>> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/ >>>> or >>>> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/ >>>> >>>> b) generate index.html pages for the sites in place of a bare >>>> directory >>>> listing - requires adding an option to feed in a different >>>> header >>>> graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects >>>> have >>>> their own branding already - see [5]). Then it's a simple matter >>>> of >>>> adapting what's already done for Central [6]. >>>> >>>> --- >>>> >>>> Refs: >>>> >>>> [0] >>>> http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh >>>> >>>> [1] >>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>>> >>>> [2] >>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>>> >>>> >>>> [3] >>>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>>> (publishes to builds/staging/${JOB_NAME}) >>>> >>>> [4] >>>> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... >>>> >>>> [5] >>>> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... >>>> >>>> [6] >>>> http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml >>>> >>>> -- >>>> Nick Boldt :: JBoss by Red Hat >>>> Productization Lead :: JBoss Tools & Dev Studio >>>> http://nick.divbyzero.com >>>> >>>> >>>> >>>> >> >> -- >> Nick Boldt :: JBoss by Red Hat >> Productization Lead :: JBoss Tools & Dev Studio >> http://nick.divbyzero.com >> >> >> > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On 22 Sep 2012, at 02:00, Rob Cernich <rcernich(a)redhat.com&gt; wrote: > Yep, as intended. We will be publishing CR, etc. into stable, > which means we'll only be overwriting if we (I) hork it up. note, we normally only put GA/Final's into development - at least for the jbosstools "all on board" releases. If you put pre-releases into /stable what do you use /development for ?

/max

hmm - looking at this - am I understanding it right when it is talking about *moving* content from "lower" sites to "higher" ones it is actually a physical move and not just update of the composite content and/or a copy of content ? What became of the logic we discussed about having builds generate specific versioned/datetimed builds which then is linked into the public/stable urls ?

Another issue I got which we discussed before - could we please stop using mixedcased urls for *anything* we do ? i.e. its not SwitchYard-Tools, its switchyard-tools; likewise its modeshape-tools, not ModeShape-Tools.

/max On 21 Sep 2012, at 20:12, Nick Boldt <nboldt(a)redhat.com&gt; wrote: > Everyone: > > I've generalized the script I gave SwitchYard for promoting their > nightlies to development (or stable) so it's much easier to > "release" > code to the community. Now with a handful of job parameters, you > can > publish your latest nightly on demand as a new build type. > > (Aside: you may find I use the terms "promote" or "publish" > interchangeably. That's because the act of "publishing" may include > the > act of renaming or "promoting" a build from a lower status > (nightly/snapshot) to a higher status (milestone/release). > Similarly, > "promoting" may include the act of "publishing" bits from within > Jenkins > (lower state, internal only) to download.jboss.org (higher state, > publicly available). Apologies in advance for the confusion this > may cause.) > > Anyhoo... the new script is here [0]. > > To use this in your own job, simply copy one of the jobs [1], [2] > mentioned below, and you can publish your bits into the standard > JBoss > Tools directory structure. > > --- > > Rob, > > Your SwitchYard-Tools-publish job [1] has been updated and should > work > but I haven't run it because I don't want to actually release one > of > your nightlies as a dev milestone. Note too that the order of the > options for which Eclipse platform to use in the published path has > been > reversed as I assume you're now building on Juno, not Indigo (with > possible backward support for Indigo). If that's an incorrect > assumption > it's easy to revert the options' order in the job config. > > --- > > Dan & Randall, > > I've tested this new script with ModeShape-Tools, and published [2] > your > latest nightly [3] as 3.0.0.Beta5, since that's what Dan was trying > to > do earlier today before he contacted me. Here are the jobs [2], > [3]. > > Here's the build promoted by the -publish job [4]. If you weren't > ready > to call it a milestone we can delete it and respin as needed -- or > just > republish on top! > > Note too that I moved your older Beta1 release from its old place > under > /modeshape/tools/updates/develop/ to here for consistency [5]. You > might > want to delete it entirely as it uses the old x.y.z.vTIMESTAMP > versioning scheme which can't be updated to the new > x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules > (users > must uninstall it first). > > Oh, and I noticed that your Beta1 was targetted at Indigo, but I > assume > your Beta5 is targetted at Juno. Is that correct? > > --- > > SOA/BRMS project leads, > > I've also created a new view in Jenkins to collate all the > trunk/JBT4/JBDS6 jobs into a single place: > > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... > > If your job(s) aren't listed, please edit the view and add them. > > Once it's complete I can spawn a duplicate view (excluding the JBDS > job(s)) which we can push to the public-facing Jenkins server, > similar > to http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/ > > Why? Because community! > > --- > > Still to do: > > a) generate composite site metadata for all the contributed > projects in > a given folder so that end users can simply look to one URL instead > of > several (JBIDE-12662) - eg., > http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/ > or > http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/ > > b) generate index.html pages for the sites in place of a bare > directory > listing - requires adding an option to feed in a different header > graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects > have > their own branding already - see [5]). Then it's a simple matter of > adapting what's already done for Central [6]. > > --- > > Refs: > > [0] > http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh > > [1] > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... > > [2] > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... > > > [3] > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... > (publishes to builds/staging/${JOB_NAME}) > > [4] > http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... > > [5] > http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... > > [6] > http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > > > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

>> What became of the logic we discussed about having builds generate >> specific versioned/datetimed builds which then is linked into the >> public/stable urls ? > > Once again these are CI builds. Why should I waste time tracking, > linking, updating, deleting? Regardless, I don't have time to > manage this. To me these are transient builds and nothing is lost > if they go missing. They are not official releases. Yes, CI builds are different but the strategy that applies to switchyard/modeshape which is "on the top of the food chain" doesn't apply uniformly to the rest. But yes, if just for CI builds this is fine 90% of the cases - I just read it as being for actual promotion and release on development and stable site. If that is not what this is about then my comments are not relevant. >> Another issue I got which we discussed before - could we please >> stop >> using mixedcased urls for *anything* we do ? i.e. its not >> SwitchYard-Tools, its switchyard-tools; likewise its >> modeshape-tools, not ModeShape-Tools. > > Not sure what you're talking about here? Here's our link: > http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... yeah the updatesites urls are at least clean :) So the url http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... raises a few questions: 1) it says indigo - why not juno ? indigo is what was used for jbt 3.3.x (maybe this is just because you haven't moved to juno yet - I just understood from last time you were moving towards that so just checking)

2) I was hoping we could leave specific version numbers out of the public updatesites (i.e. http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... vs http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli...) - of course if you got multiple versions for jbt 3.3 indigo then it makes sense but that wasn't my understanding you were doing.

3) if its CI builds, why isn't this http://download.jboss.org/jbosstools/updates/nigtly/indigo/soa-tooling/sw... ?

> As for internal links, I don't really care. Don't we have better > things to do with our time than change the case of our build jobs? Most of the time yes, and for one project sure its irrelevant, but when its inside ~250 jobs then it just seems messy and it gets harder to see what is actually following conventions/same structure. But yes, its probably just me after having to explain tons of times to users internally and externally the mess of names produced.

/max > >> >> /max >> >> >> On 21 Sep 2012, at 20:12, Nick Boldt <nboldt(a)redhat.com&gt; wrote: >> >>> Everyone: >>> >>> I've generalized the script I gave SwitchYard for promoting their >>> nightlies to development (or stable) so it's much easier to >>> "release" >>> code to the community. Now with a handful of job parameters, you >>> can >>> publish your latest nightly on demand as a new build type. >>> >>> (Aside: you may find I use the terms "promote" or "publish" >>> interchangeably. That's because the act of "publishing" may >>> include >>> the >>> act of renaming or "promoting" a build from a lower status >>> (nightly/snapshot) to a higher status (milestone/release). >>> Similarly, >>> "promoting" may include the act of "publishing" bits from within >>> Jenkins >>> (lower state, internal only) to download.jboss.org (higher state, >>> publicly available). Apologies in advance for the confusion this >>> may cause.) >>> >>> Anyhoo... the new script is here [0]. >>> >>> To use this in your own job, simply copy one of the jobs [1], [2] >>> mentioned below, and you can publish your bits into the standard >>> JBoss >>> Tools directory structure. >>> >>> --- >>> >>> Rob, >>> >>> Your SwitchYard-Tools-publish job [1] has been updated and should >>> work >>> but I haven't run it because I don't want to actually release one >>> of >>> your nightlies as a dev milestone. Note too that the order of the >>> options for which Eclipse platform to use in the published path >>> has >>> been >>> reversed as I assume you're now building on Juno, not Indigo >>> (with >>> possible backward support for Indigo). If that's an incorrect >>> assumption >>> it's easy to revert the options' order in the job config. >>> >>> --- >>> >>> Dan & Randall, >>> >>> I've tested this new script with ModeShape-Tools, and published >>> [2] >>> your >>> latest nightly [3] as 3.0.0.Beta5, since that's what Dan was >>> trying >>> to >>> do earlier today before he contacted me. Here are the jobs [2], >>> [3]. >>> >>> Here's the build promoted by the -publish job [4]. If you weren't >>> ready >>> to call it a milestone we can delete it and respin as needed -- >>> or >>> just >>> republish on top! >>> >>> Note too that I moved your older Beta1 release from its old place >>> under >>> /modeshape/tools/updates/develop/ to here for consistency [5]. >>> You >>> might >>> want to delete it entirely as it uses the old x.y.z.vTIMESTAMP >>> versioning scheme which can't be updated to the new >>> x.y.z.Beta5-TIMESTAMP features due to OSGi's versioning rules >>> (users >>> must uninstall it first). >>> >>> Oh, and I noticed that your Beta1 was targetted at Indigo, but I >>> assume >>> your Beta5 is targetted at Juno. Is that correct? >>> >>> --- >>> >>> SOA/BRMS project leads, >>> >>> I've also created a new view in Jenkins to collate all the >>> trunk/JBT4/JBDS6 jobs into a single place: >>> >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>> >>> If your job(s) aren't listed, please edit the view and add them. >>> >>> Once it's complete I can spawn a duplicate view (excluding the >>> JBDS >>> job(s)) which we can push to the public-facing Jenkins server, >>> similar >>> to http://hudson.jboss.org/hudson/view/SOA-Team/view/SOA_Tooling/ >>> >>> Why? Because community! >>> >>> --- >>> >>> Still to do: >>> >>> a) generate composite site metadata for all the contributed >>> projects in >>> a given folder so that end users can simply look to one URL >>> instead >>> of >>> several (JBIDE-12662) - eg., >>> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooling/ >>> or >>> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling/ >>> >>> b) generate index.html pages for the sites in place of a bare >>> directory >>> listing - requires adding an option to feed in a different header >>> graphic (JBIDE-12660), as the various SOA/BRMS Tooling projects >>> have >>> their own branding already - see [5]). Then it's a simple matter >>> of >>> adapting what's already done for Central [6]. >>> >>> --- >>> >>> Refs: >>> >>> [0] >>> http://anonsvn.jboss.org/repos/jbosstools/trunk/build/publish/promote.sh >>> >>> [1] >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>> >>> [2] >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>> >>> >>> [3] >>> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/SOA-Team/view/SOASt... >>> (publishes to builds/staging/${JOB_NAME}) >>> >>> [4] >>> http://download.jboss.org/jbosstools/updates/development/juno/soa-tooling... >>> >>> [5] >>> http://download.jboss.org/jbosstools/updates/development/indigo/soa-tooli... >>> >>> [6] >>> http://anonsvn.jboss.org/repos/jbosstools/trunk/central/site/pom.xml >>> >>> -- >>> Nick Boldt :: JBoss by Red Hat >>> Productization Lead :: JBoss Tools & Dev Studio >>> http://nick.divbyzero.com >>> >>> >>> >>> _______________________________________________ >>> jbosstools-dev mailing list >>> jbosstools-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jbosstools-dev >> >>