ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Clitheroe <g.clithe...@gmail.com>
Subject Re: latest-revision latest-strategy & integration versions
Date Mon, 30 Aug 2010 20:38:08 GMT
Hi,

I might have miss understood the first question but this may help (and
address the downside concerns).

Publishing to the repo (archiva) is only done by a successful build in the
CI server (Bamboo) i.e, push on green.

A commit that builds and passes all its tests will publish a snapshot.

A release is done using a manually triggered build plan in Bamboo which only
a smaller group of users can run.  The only difference is the additional
param to ant:  -Divy.status=release  Asides from that I think it's just the
normally available Ivy setup.

The relevant targets in build-base.xml are

-ivy-get-next-final-buildnumber            check the buildnumber for the
next final release.
 -ivy-update-final-buildnumber              update the buildnumber for a
final release.
 -ivy-update-release-candidate-buildnumber  update the buildnumber for a
release candidate.
 -ivy-update-snapshot-buildnumber           update the buildnumber for a
snapshot release.

If its helpful try checking out code from here

http://codegeo.org/repos/cwb/GeoNetCWBQuery/trunk/

Run 'ant setup-nb-build-environment' to bootstrap ivy and the dependencies
and the you should be able to run all the other targets.  Unless we goofed
you won't be able to publish to codegeo but you should be able to see things
in action.

Cheers,
Geoff

On Thu, Aug 26, 2010 at 4:58 AM, Mitch Gitman <mgitman@gmail.com> wrote:

> Awesome. Thanks, Geoff. Whenever you get back from your travels, I'd be
> curious to know if you had to specify your own latest-revision strategy to
> get this working.
>
> If anyone else out there is prolifically versioning integration builds,
> whether with a buildnumber or a timestamp, how'd you get that working? Did
> you have to define your own latest-revision strategy?
>
> Now that I think of it, one very simple approach is to just prolifically
> version all integration builds, including those on a developer machine. For
> this, you don't even need a special suffix. So you might produce:
> 2.0-201008250832
> 2.0-201008250842
> etc.
>
> And then in dependencies you can ask for:
> rev="2.0-+"
> (assuming you know you want an integration version)
>
> The only downside to this approach is that each developer is producing a
> new
> revision on their local machine every time they do a publish. This seems
> like overkill, but maybe it's not such a bad thing. Maybe it's a good thing
> if you want to compare how a change affects a dependency's behavior.
>
> This looks like what happens with Geoff's codegeo project. Developer builds
> will prolifically version with the *-SNAPSHOTx auto-incrementing. This
> raises the potential for a conflict if a developer build produces
> *-SNAPSHOT5 based on ivy:buildnumber because the latest version in the
> shared repo is *-SNAPSHOT4 and then subsequently the shared repo gets its
> own *-SNAPSHOT5.
>
> On Tue, Aug 24, 2010 at 2:19 PM, Geoff Clitheroe <g.clitheroe@gmail.com
> >wrote:
>
> > Hi Mitch,
> >
> > I'm heading for a plane and will be away for a while.  This may be useful
> -
> > how we're doing snapshots (for this repo anyhow)
> >
> > http://codegeo.org/confluence/display/codegeo/Publishing
> >
> > http://codegeo.org/repos/codegeo/build/trunk/build-base.xml
> >
> >
> > Cheers,
> > Geoff
> >
> >
> > On Wed, Aug 25, 2010 at 3:14 AM, Mitch Gitman <mgitman@gmail.com> wrote:
> >
> > > Bumping this to the top to see if I can get any takers. I'm
> particularly
> > > interested in seeing how anyone was able to work a timestamp or
> > buildnumber
> > > into the mix and whether that needed a custom revision strategy.
> > >
> > > On Sun, Aug 22, 2010 at 4:19 PM, Mitch Gitman <mgitman@gmail.com>
> wrote:
> > >
> > > > I'm grappling with some of the choices surrounding integration
> > versions.
> > > >
> > > > One assumption I want to make is that non-integration
> versions—versions
> > > > that represent releases—do not have any special suffixes. So I would
> > > release
> > > > version 2.0 of something rather than 2.0-FINAL or 2.0-RELEASE or
> > > something
> > > > like that.
> > > >
> > > > I do want to use a special suffix to represent integration versions.
> > One
> > > > combination that makes sense to me is -DEV and -CI. It seems that I
> > > should
> > > > specify something like the following in my Ivy settings:
> > > >   <latest-revision name="mylatest-revision"
> > > > usedefaultspecialmeanings="false">
> > > >     <specialMeaning name="CI" value="-2"/>
> > > >     <specialMeaning name="DEV" value="-1"/>
> > > >   </latest-revision>
> > > >
> > > > Does this look right? Notice no hyphen prefix. And as long I'm
> > mentioning
> > > > the suffixes -DEV and -CI, anyone care to suggest a better suffix or
> > > > combination? Of course there's always -SNAPSHOT.
> > > >
> > > > Now suppose I want to do prolific versioning where each integration
> > > version
> > > > gets its own timestamp. It seems like overkill to do prolific
> > versioning
> > > on
> > > > publishes on a developer machine. Only for the CI server do I only
> want
> > > to
> > > > produce a unique, timestamped version on each publish. So I want to
> > have
> > > the
> > > > ordering from newest to oldest go something like:
> > > > 1. 2.1-DEV on developer machine
> > > > 2. 2.1-CI-201008221522 on CI-published repository
> > > > 3. 2.1-CI-201008220801 on CI-published repository
> > > > 4. 2.1-CI-201008201948 on CI-published repository
> > > > 5. 2.0 on release repository
> > > >
> > > > Do these look like reasonable conventions, or could someone recommend
> a
> > > > better convention for producing a unique version from each successful
> > CI
> > > > build?
> > > >
> > > > If these conventions do look reasonable, how do I incorporate the
> extra
> > > > timestamp suffix into my latest-revision latest-strategy in Ivy
> > settings
> > > to
> > > > ensure that CI versions get ordered by timestamp but still get
> treated
> > as
> > > > older than DEV and release builds?
> > > >
> > > > P.S. I need to go back over some old ivy-user threads on this topic.
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message