Jenkins Settings problem

[Manoj Kumar Bardhan]

Hi,

I am using Maven Release Plugin for automate the build & release process.Its working fine but one problem I am facing.

I have created a job, which is checking trunk in every 15 mins, if any changes found it starts the build & release process.And its working fine.

But , small problem is when the release:prepare is executing , it is creating the tag and auto increment the trunk/pom.xml version (with SNAPSHOT) to next release version-SNAPSHOT.

Suppose my current build version is 2.0-SNAPSHOT. After successfully build it create the tag with only 2.0 (without SNAPSHOT). Also it auto increments the pom.xml inside trunk to 2.1-SNAPSHOT.

The problem is , when my Jenkins (crontab) checking the trunk in every 15 mins ,it is found a new version inside the trunk (i.e. pom.xml ). And it creates another build again. This process is happening again and again.Where as I know there is no code changes in trunk, only version has incremented by release:prepare command.

How to avoid this.


What mistake I did.
Thanks in Advance.

[Baptiste Mathus]

I understand you're releasing a new version for almost every commit. Though I like the idea of continuous delivery or equivalent I'm not sure it's conceptually correct this way.
For your issue, if you really want to stay this way, I suppose I would just try to update the working copy at the end of the build, so that next check doesn't see the release commit as a content commit.

Cheers

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Waite]

The git SCM plugin has a way to ignore changes to certain files, by specifying those exclusion patterns with a regular expression.  It is in the "advanced" section of the plugin configuration items on the job configuration page.  Your SCM plugin may have a similar setting which would allow you to ignore changes to that file as part of the process (assuming that file changes rarely for other reasons).  

We used a technique like that quite successfully, though our version information was stored in a separate file dedicated to only storing the version number.

[Baptiste Mathus]

Not sure that could work correctly. If you always ignore pom.xml changes, you'll sure have other issues soon.

Just had a look inside SVN config and found some interesting parameter (which I don't find in the Git plugin, btw) : "Excluded Commit Messages".
Ignoring the "copy to tag" and so on messages, you might still be able to watch pom.xml file for other commits than the release ones.

And if the git plugin doesn't support it yet, I suppose this could be a useful addition.

2013/9/16 Mark Waite <mark.ea...@gmail.com>

Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor ! nbsp;!

[Richard Bywater]

Do you really want to build a version every build? I've not used Maven within Jenkins but I'd imagine you'd have a separate release job that did that part?

Richard.

--

[Manoj Kumar Bardhan]

Thanks for your reply.Yes.Actually its working.But when release:prepare execute it re-increment the trunk pom.XML version.And successfully create the tag with out snapshot.And when my Jenkins runs after 15 mins it found that a new version in trunk , and it start build process again. Repeats same ...in every 15 mins.But, I know there is no code changes.

You received this message because you are subscribed to a topic in the Google Groups "Jenkins Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-users/CQib5RUIWzo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-use...@googlegroups.com.

[Eric Pyle]

When I have worked with Jenkins and Maven, we also had a build trigger on the trunk. But it does not trigger a release build, instead it triggers a snapshot build. Snapshot build does not execute release:prepare, so it does not cause a change in source control in the trunk. You do get one technically unnecessary build of the trunk when you perform a release build and it checks in the new tag, but that's it. A release build is only triggered manually when you need to release a stable set of artifacts to others, e.g. for testing before a public release.

Eric