0
votes

We are using IVY on our project and I have recently setup a Jenkins server so that every time a trunk check in is performed the following happens.

  1. Jenkins SCM poll detects change and notifies IVY plugin.
  2. IVY plugin triggers ANT build for changed module and triggers build of downstream modules.
  3. Built modules are then published to central IVY repo versioned as 1.0-SNAPSHOT

Each module ivy.xml on trunk declares dependencies using rev="latest.integration" and the ivysettings.xml file declares the resolver as follows. This ensures later SNAPSHOTS are pulled down to the local IVY repo.

    <resolvers>
    <chain name="chained" returnFirst="true">
        <filesystem name="libraries" changingPattern="1.0-SNAPSHOT" changingMatcher="exact" checkmodified="true">
            <ivy pattern="${ivy.repo.dir}/[organisation]/[module]/[revision]/ivy.xml"/>           
            <artifact pattern="${ivy.repo.dir}/[organisation]/[module]/[revision]/[artifact].[ext]"/>
        </filesystem>
    </chain>
</resolvers>

Now this works fine whilst developing on trunk, but I am confused on how to take this forward so that we can publish release artifacts. If I am correct SNAPSHOTS should never be used in a production deployment?

I was thinking whether to implement a weekly build that runs at the weekend and performs the following.

  1. Tears down the Jenkins workspace.
  2. Checks out trunk from SVN.
  3. Runs a full build and executes all unit tests.
  4. If 3 runs to success for ALL modules then publish versioned artifacts eg -WKYY.1 to IVY repo.

Now if steps 1-4 are correct, do I then TAG SVN and create branches for ALL modules so that the IVY.xml files can be checked in which state the correct dependency version numbers?

1

1 Answers

0
votes

I can share how we have things setup, although our situation is different.

We have a separate branch for release builds, and a separate job that polls this branch and makes release builds from it. Our release process consists in part of merging the master branch to the release branch. This can be automated of course. In your case, perhaps you could do it if step 3 succeeds.

So for each project we have one set of jobs (tracking "master") that handle the snapshot builds, and one set of jobs (tracking "release") that handle the release builds. The jobs are similar for the most part, but different.