Hudson Perforce plugin - how can I automatically update versions without repeatedly triggering a build

I'm trying to get continuous integration working using Hudson, Maven & Perforce (with an scm poll used to trigger each build)

One of the requirements is to automatically update POM snapshot version numbers following each successful build.

This is trivial using the Maven release plugin, but the act of checking in the newly versioned POMs triggers another build - which co开发者_运维百科ntinues ad infinitum.

Is there any way of checking in version updates without triggering another build? There doesn't seem to be any way of excluding specific user checkins, specific changelists, or specific files when the scm poll makes the decision to rebuild.

This seems like a basic requirement - been doing it for years using Cruise Control / Ant / Perforce,

Cheers,

Mark

I have been contemplating a move to Hudson, but the inability to exclude specific files from the scm poll would be a deal breaker. Did you also ask this question on the Hudson mailing list?

users <at> hudson <dot> dev <dot> java <dot> net

The only workaround I can see from reading through the docs seems to be triggering builds based on p4 triggers, where you could then programmatically do whatever you want, but that doesn't seem to be a very simple approach.

I don't believe there is any way to configure Hudson to omit part of a Perforce workspace when polling. You may have better luck by setting up two different workspaces - one for build test using a default POM and one for your releases with the auto-updated release POM. The two workspaces could differ on just this one file and modifying the release POM would not trigger a new build.

Check out how to do individual file mapping in a workspace in the P4Guide.

Its possible to update the description of a changelist after it has been submitted, so if you build to a certain changelist number you can then update the description of that changelist to include your build number. This shouldnt trigger a new build.

What is "POM"?

You can have Hudson "Create or Update Label in Perforce" (see near the bottom of your project's configuration.) You could use that along with the BUILD_NUMBER environment variable that Hudson provides, giving you unique build numbers and stamped P4 labels of said build.

I have all tagging, ChangeLog updates, and packaging done by our checked in build code. This allows us to:

• Create RC and appropriate tags without starting anther build
• Allows us to debug all aspects of our build on any dev machine, not just those with Hudson.
• Allows us to exactly recreate how a package, tag, etc was done in at any point in the past.

I had a similar problem checking in compiled src. I was able to find an alternative but i did consider the following.

1. In hudson specify a child folder of your project to poll. I.e. don't actually have hudson check out your project, just an incidental folder.

2. Add a shell script to check out your project proper.

3. Run you normal scripts.
4. check in your pom. The trick here is that the folder being polled won[t have changed at this point.

Not ideal, but works.

The perforce plugin has had polling masks for a while now. It's in the Advanced section under "View Mask".

Basically, you list a subset of files that you want polling to check for changes. Unfortunately there's no easy way to exclude files, so you'll have to create a list of file specs that specify everything BUT the file you want to exclude. So if the version is contained in a pom.xml, I would need to specify the files and directories that don't contain it.

For example, if your directory structure looked like this:

./pom.xml
./lib/
./src/

You would specify,

//depot/project/lib/...
//depot/project/src/...

as the view mask, and check the checkbox to use it only for polling. There are a few limitations with this feature, such as not being able to use '-' to exclude file specs, but it's still a workable solution for now.