Mitch Gitman wrote:
Thanks again for the insights. Few brief comments inline below.
On Thu, Nov 20, 2008 at 3:10 AM, Jonathan Oulds <[EMAIL PROTECTED]> 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
