1:02 p.m.
----- Original Message -----
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 ?
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.
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...
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?
/max
On 21 Sep 2012, at 20:12, Nick Boldt <nboldt(a)redhat.com> 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