I have a project using Ivy which is built via Jenkins.  I have two
branches for this project (a stable branch and a current development
branch, which is the master branch in Git).

In Jenkins I have one build configured for each branch (I don't want to
mix the build histories).  I have a post-commit hook in my Git
repository which checks for the branch(es) of the commit and then uses
to wget to retrieve the URL that triggers the build that corresponds to
the branch of the commit.

The problem that I am experiencing has to do with making changes in
quick succession on the two branches.  My Ant build.xml does the normal
build routine and at the end publishes the artifacts into my own local
Ivy repository.  When the builds run concurrently (because, for example,
I make a commit one branch and then immediately cherry-pick the commit
to the other branch, the build that finshes last uses the ivy.xml
desriptor from the build that finishes first.  This is very frustrating
as it breaks all sorts of things.  I can go into Jenkins and force a
rebuild of the one that finished last and everything turns out
correctly, with the correct descriptor being published the second time.

I looked through the Ivy source code and found a reference to a delivery
list file that looks in ${java.io.tmpdir}/delivery.properties.  I tried
explicitly setting the ivy.delivery.list.file using Ant's <tempfile/>
task to ensure that concurrent builds won't accidentally touch the same
file.  I was able to confirm that instead of /tmp/delivery.properties
that the Ivy publish task was using the randomly generated file name Ant
put into the ivy.delivery.list.file property.

Even with that, though, I am still seeing the buggy behavior.  That is,
the build that finishes last uses the same descriptor as the build that
finishes first (line for line identical except for the revision and
publication attributes of the info tag.

Any help on this would be appreciated.

Regards,

-Roberto
-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com

Reply via email to