Ivy Repository and artifact versioning

I have been tasked with moving our teams CI builds onto an existing TeamCity (4.0.x) server, part of which is seeing if we can use it's Ivy Repository features to replace the currnet setup we have.

So currently, we call the "ivy publish" task as part of our CI builds, which publishes the files (JARs and ivy.xml) into the local repository on the CI server. Also on that server we run an apache instance which serves up that repository so that other developers can use those published artifacts, using them as "snapshot" versions which other projects depend on.

We build both "trunk" builds and "release branch" builds, so moving these into a few TeamCity projects with various "build configurations was an easy translation. But tweaking these projects to serve the snapshot build artifacts up was not quite so easy, but eventually I had the following Ivy file :

<ivy-module version="1.3">
  <info organisation="acme" module="test"/>
    <dependency org="org" name="bt63" rev="latest.lastSuccessful">
      <include name="commons-util" ext="jar"/>

So my little test module relies on the latest successful build of our "commons" project, which produces a handful of common jars, including common-util.jar. And this works now, pulling this project down. But it's just a test - looking at our current real projects we have the following ivy files :

<ivy-module version="1.3">
    <info organisation="acme" module="real project"/>

        <!-- commons dependencies -->
        <dependency org="acme" name="commons" rev="${commons.version.pattern}" />

           <include name="commons-util" ext="jar"/>

Typically the commons.version.pattern will be a variable such as 1.0.+, giving us the latest snapshot build of a specific version.

Now organisation = "org" seems somewhat random, and name="bt63" not great either, but as we do windows builds, so cannot go with the "commons::trunk" alternative, as Windows is not happy with '::' in file names ! From what I can see, these have been raised in exisiting issues though.

I think my main concern here is that in our setup the "name" implies the project, and the "rev" property directs you to which version (be it release branch or trunk) you are working off. But with TeamCity, it seems more common to have one build configuration per release branch / trunk version, so therefore the "name" implies both the project and the version, where as rev is merely the version off that branch you want to use (always "latest" in our case).

Pretending we had some fix such that I don't have to constantly update all my ivy files whenever I want to add a new branch (because it will mean a new build configuration with a new build id), I still would ideally like multiple build configurations of a project to all post to the same module, albeit with different versions which I will setup on a per-build configuration basis.

E.g. I could have 2 configurations of the commons project, one building version 1.0.{build number} and the other building version 1.1.{build number), both building to the same "org" and "name" in the repository.

In fact, couldn't TeamCityt use the ivy files that are published as part of my builds ? It has most, if not all, of this information in there. Would sure beat me having to duplicate it into a TeamCity admin dialog ! Or is this a request too far for now ?!

Thanks for any enlightenment on the workings of ivy with TeamCity - at the moment we are looking to grab the artifacts with a shell script and move them into the expected repository format - but this will make our setup as complex and patchy as our old one, so I would much prefer to look into a proper integrated TeamCity solution, esp. as the basic Ivy support clearly is there.


Comment actions Permalink

Bad form to respond to your own thread, but I don't think anyone else is keen to

Having spent a week thinking over how we use Ivy, I think I can boil down my issues with the Team City Ivy offering to something a little clearer :

We use Ivy to publish artifacts to our local developer repositories when making changes, and to publish builds to our "CI repository" when developers check code in.

This means the published Ivy file must be identical on both repositories, in terms of organisation, modules and published artifacts; so when my build asks for the latest build of "common-utils", it will get it either from the local store, or from the CI repository (I don't care which).

So our core problems are going to stem from TeamCity mandating than we change the organisation to "org" and the module name to "b123" or similar, whereas currently we would have an organisation named after my workplace and a module name of "common-utils".

The solution would seem that rather than TeamCity constructing the Ivy file itself, it should use the Ivy file of the artifact itself (if present), and publish using it's settings. However, I guess this is quite different from how TeamCity's Ivy repository has been designed, so my real question is would such a change potentially make it into a future build of TeamCity ?

Until then, it seems maintaining our Ivy Repository external to TeamCity is the only way of keeping control over our published artifact naming.

Keen to hear any feedback on this or future plans of the TeamCity Ivy offering !


Comment actions Permalink

TeamCity acts like Ivy repository for read access, but it does not currently support publishing of the artifacts in the Ivy style. So I think there are two choices:
- do not use TeamCity artifacts feature (or publish artifacts to both TeamCity and your Ivy repository) and retrieve artifacts from Ivy repository only
- always use TeamCity artifacts even for developer's workspaces and do not use Ivy repository. For this you need to write a scripts which will fetch artifacts from the TeamCity with help of Ivy


Please sign in to leave a comment.