ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Oulds <jonat...@sbdev.net>
Subject Re: buildnumber Ant task & automated updates of ivy.xml
Date Fri, 21 Nov 2008 10:26:23 GMT


Mitch Gitman wrote:
> Thanks again for the insights. Few brief comments inline below.
> 
> On Thu, Nov 20, 2008 at 3:10 AM, Jonathan Oulds <jonathan@sbdev.net> wrote:
> 
>> Let me try and deal with each of your points one by one and explain how I
>> am trying to solve each issue.
>>
>> - How to make ivy work differently when projects are build by the CI
>> machine versus builds on development machines.
>>
> 
> This makes me wonder now why you found the need for Ant to distinguish
> between a CI build and a manual developer build. As far as Ivy is concerned,
> wouldn't it simply be a matter of CI calling one set of targets, i.e.
> publish, and developers calling another set of targets? Anyway, no big deal.
> 
> 
>> I include an environment variable on the CI machine that can be read and
>> used to parametrise the build.  Here is a snippet of ant code.
>>
>> <property environment="env"/>
>> <property name="env.builder" value="${env.BUILDER}"/>
>> <condition property="build.ci">
>>  <equals arg1="${env.builder}" arg2="CI"/>
>> </condition>
>> <target name="publish-ci" if="build.ci">...</target>
>> <target name="publish-dev" unless="build.ci">...</target>
>> <target name="build" depends="publish-ci, publish-dev"/>
>>
>> - As to including the version number in the ivy file prior to publish.
>>
>> You are correct, in that the by using the build number task you are not
>> setting a concrete revision for your module until you publish.  The other
>> alternative is to hard code the revision into the ivy file pre-delivery.
>>  However surely this implies that the developer (or whatever is building the
>> module) knows the revision prior to publishing.
>>
>> As an example we have our project source under SVN.  Our CI inspects the
>> project then builds and publishes if it detects any changes.  however if we
>> hard coded the revision number into the ivy file then our CI machine would
>> have to update the ivy file with the new version and do a commit.
>>
> 
> This is precisely what we did on my previous team. The CI-invoked build
> updated the revision build number in the ivy.xml file in source and then
> checked in the updated file. This seems like a lot of trouble to go to, and
> a potential source of version inconsistencies when its only purpose is as a
> kind of documentation.

I think either I am misunderstanding you or t'other way around, we are 
not storing the ivy revision number under SVN except as part of the tag 
name created by CI on a successful build.  The ivy file we have under 
SVN does not contain it's own revision, this is only inserted into the 
delivered ivy file and is derived from the latest build number in the 
ivy repository.

> 
> As I alluded in the lengthy post I sent earlier today, it's becoming
> apparent to me that your project source proper is not the ideal place to be
> keeping track of the current Ivy version of that project. It's like Ivy does
> not want to be used in this way. Not only do you have to keep track of the
> version manually through some scheme of your own, but again you have an open
> invitation for your current version (as recorded in project source) to get
> out of sync with the latest version that exists in the Ivy repository.
> 
> 
>> That didn't sound like a good idea to us, so we headed down the route of
>> not having the version numbers specified in the ivy file and only resolving
>> the correct version number upon delivery.  Our CI machine will auto
>> increment the build number, when a module changes significantly we do a
>> special build of the module updating the major or minor version.
>>
>> long post, hope some of it is helpful
>> any advice / comments are welcome
>>
> 


Mime
View raw message