Re: [jbosstools-dev] New promote script & Jenkins view for use with JBT SOA Tooling components (and later, JBT Core components in github, too)

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