My regular CI build takes 1 hr and a release build takes 2 hrs. Can I skip the release:prepare and directly do a release:perform to save time? What will I miss?
Any other way to decrease the release build time if I cant skip this?
Thanks
Nube to mvn
The short answer is no you can't skip the release:prepare goal. If you want more then read on.
From the maven release plugin documentation:
Prepare for a release in SCM. Steps through several phases to ensure the POM is ready to be released and then prepares SCM to eventually contain a tagged version of the release and a record in the local copy of the parameters used.
What this actually does is the following:
Modify all your x-SNAPSHOT versions to simply x. So 1.0-snapshot will turn into 1.0
Build everything to make sure this still compiles and tests after the version change
Commit the changes (And tag them in your SCM)
Upgrade all the versions to the next SNAPSHOT version, in our case 1.1-SNAPSHOT
Commit this new change
An intended by-product of this process are files with the poms to be built for the release:perform goal, so that's why you can't skip the release:prepare.
If you're still interested in shortening your build time, and do not care for all the commits to SCM you can implement your own release mechanism (which I do not recommend) using maven-versions-plugin and maven-deploy-plugin. See this for details.
Related
Say I have an artifact with version 1.0.0-SNAPSHOT (in the SVN). When I call Maven Release Plugin, I want it to build version 1.0.0-1, but leave the SVN at 1.0.0-SNAPSHOT. The next release then should be 1.0.0-2 (still with 1.0.0-SNAPSHOT in the SVN) etc.
How can I achieve this behaviour?
PS: If the build number should better be determined by a build server as Jenkins, I would also be glad to hear about that.
We have 2 branches in github,
master
release
In our jenkins we have a job for each of these branches.
We want to increment a version number programmatically for release each time jenkins builds the release. We want also to increment the version number in the github release branch. Can you give me some directions on how to do it and what jenkin plugins i need? Thanks
This can be performed using a simple command:
mvn release:prepare release:perform --batch-mode
Explanation:
release:prepare
Prepare for a release in SCM. Steps through several phases to ensure the POM is ready to be released and then prepares SCM to eventually contain a tagged version of the release and a record in the local copy of the parameters used. It will update your version number from e.g. "1.0.1-SNAPSHOT" to "1.0.1" and commit it to the tag. Also working version will be incremented and updated to "-SNAPSHOT" again, e.g. "1.0.2-SNAPSHOT".
This can be followed by a call to release:perform. For more info see example
release:perform
Perform a release from SCM, either from a specified tag, or the tag representing the previous release in the working copy created by release:prepare. For more info see example
--batch-mode allows a non-interactive script executeion. For details please read about maven-release-plugin
Use the maven release plugin to handle incrementing the version number. At that point all you have to do is have the Jenkins build run maven with the release plugin goals.
Here is a good article on it.
http://www.vineetmanohar.com/2009/10/how-to-automate-project-versioning-and-release-with-maven/
With that all you have to do in Jenkins is have it run the following command on the checked out repository.
mvn release:prepare release:perform -B
I'm using the maven-release-plugin and I'm noticing that it appears to change the released version BACK to -SNAPSHOT at the end.
Here's the command line args that I'm passing to maven:
--batch-mode release:prepare -DupdateWorkingCopyVersions=false -Darguments="-DskipTests -Djava.awt.headless=true -Dmaven.javadoc.failOnError=false"
Everything appears to go well - and I notice a commit and a push from the plugin where all of the proper version numbers are indeed updated to NOT have the -SNAPSHOT.
[WARNING] Ignoring unrecognized line: ?? myProject/pom.xml.releaseBackup
I see a few of these warnings ^ in the log file (not sure if this is relevant, but appears to be related to the release plugin)
Finally I see that the plugin modifies the POMs again:
[INFO] Transforming 'myProject POM'...
[INFO] Updating my-project to 6.2-SNAPSHOT
Following this the plugin makes and pushes a commit with the following:
[maven-release-plugin] rollback changes from release preparation of myProject-6.2
Why is this last bit happening?
I don't understand the lifecycle of release:prepare or release:perform. Why does all of my code appear to be built twice?
Any help appreciated. Thanks
As I understand it, release:prepare
Updates the POM files to the version that was specified
performs the build, which runs the tests
performs other validations (ie, no dependencies to SNAPSHOT artifacts)
Commits the changes (which should be restricted to the POM files and their versions)
Tags the source that was just committed
Updates the pom files back to the nominated SNAPSHOT version
Commits those changes
Note: I'm not sure if that's the specific order. The above list is not an exhaustive list, it's just my recollection.
At this point, the release doesn't exist. That's what release:perform does. Release:perform checks out the code against the TAG and builds the artifacts against the tagged source.
This is why release:prepare moves it back to the snapshot version. It's simply preparing the source to have a release built against it. Developers working on that branch, once the tag is cut, can continue to commit changes without affecting release:perform. It also allows a release to be re-cut at a later date, as it is built against the tag.
Of course, there are variations to this plugin which is documented. But, as I understand it, this is a common workflow for this.
We use Maven with Subversion internally. We also use Maven's Release plugin. We noticed the issue described below when running through the following (correct, I presume) steps.
1. We run release:prepare:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thus creating tag myproject-1.0.0.
Maven updates the trunk version to 1.0.1-SNAPSHOT.
2. We run release:rollback:
Maven resets the trunk version to 1.0.0-SNAPSHOT.
Maven does not remove the tag, because Maven doesn't do this kind of stuff.
3. We commit more changes to trunk, obviously against version 1.0.0-SNAPSHOT.
4. We run release:prepare again:
Maven updates the trunk version to 1.0.0.
Maven runs svn copy trunk/myproject tags/myproject-1.0.0, thinking it created tag myproject-1.0.0 out of the latest trunk. But, alas, Subversion (1.6 and 1.7 alike) will instead create tags/myproject-1.0.0/myproject on Maven's behalf.
5. We run release:perform:
Maven checks out the contents of tag myproject-1.0.0.
Maven builds the contents and deploys the result to Nexus.
The problem is obvious: the change in step 3 did not make it into the tag. We are now releasing 1.0.0 without the change in it.
The questions are: How can we fix this? Is Maven's release rollback feature inherently broken?
In fairness, rollback should reset the project and SCM to a state that allows a second prepare to occur. This includes removing the tag. The answer is now apparent (Googling "maven release rollback remove tag"):
http://maven.apache.org/maven-release/maven-release-plugin/examples/rollback-release.html:
The created branch/tag in SCM for the release is removed. Note: This
is not yet implemented so you will need to manually remove the
branch/tag from your SCM. For more info see MRELEASE-229.
The resolution would then be to force release:rollback to include a command to delete the SCM tag using something like org.codehaus.mojo:exec-maven-plugin. Short of this, wrap rollback inside a script that does that externally.
As you've discovered, release:rollback doesn't have a whole lot of utility when it doesn't clean up SCM. What our shop has done is setup our Jenkins automation to run "mvn release:prepare release:perform" in combination with the Jenkins M2 Release Plugin.
If it fails we need to delete the tag in Subversion but, then again, we would have to do this anyway with rollback.
I have a Maven pom.xml, I build project and release project deploy with Jenkins.
But before and after build "release version" we need set my version in
For example:
I have in pom.xml
<properties>
<version-own>0.0.21-SNAPSHOT</version-own>
</properties>
before release I need set like this
<properties>
<version-own>0.0.25</version-own>
</properties>
after release I need set like this
<properties>
<version-own>0.0.27-SNAPSHOT</version-own>
</properties>
How can this be done?
If you don't have to use your own version property, consider the following that will operate on your <project><version>0.0.21-SNAPSHOT</version></project> element:
mvn versions:set versions:commit -DnewVersion="0.0.25"
That will modify your pom and adjust the version to your liking. You'll likely want to commit this change to your source code control repository, for this the scm plugin's scm:checkin goal works just fine (assuming you want this to be automated):
mvn scm:checkin -Dincludes=pom.xml -Dmessage="Setting version, preping for release."
Then you can perform your release (I recommend the maven-release-plugin), after which you can set your new version and commit it as above.
The versions plugin is your friend. Scripting the above would likely involve some parameterized build, or preferably the groovy plugin for jenkins which allows you to get the maven-specific build variables.
For starters, you can do it by hand. If your build follows maven conventions well, you could probably leverage one of a couple of maven plugins that exist for helping with the management of version numbers.
The maven-versions-plugin helps automate manual changes to version numbers. It has nice CLI commands to help tune up your poms before doing releases.
Then there's the maven-release-plugin that automates the whole process of cutting a release. It will change your snapshot to a release version, then roll it to the next snapshot after the release build. During all this process it commits discrete versions of the poms to source control.
Again, the secret to seeing success in the more automated bits of the maven community is whether your build is doing things the maven way or not. Hacked, highly tweaked, non-conventional builds usually have a lot of barriers to successful use of the release plugin.
There is one way to to that easily. With one command you can change whichever part you want:
For cut and paste:
mvn build-helper:parse-version versions:set -DbuildNumber=555 '-DnewVersion=${parsedVersion.majorVersion}.${parsedVersion.minorVersion}.${parsedVersion.incrementalVersion}-${buildNumber}'
For clarity:
mvn build-helper:parse-version versions:set -DbuildNumber=555
'-DnewVersion=
${parsedVersion.majorVersion}
.${parsedVersion.minorVersion}
.${parsedVersion.incrementalVersion}
-${buildNumber}'
This is a concise example how to update versions in one go with build values
Build-helper plugin supports regex replacements, and can even parse version numbers if need be.
http://www.mojohaus.org/build-helper-maven-plugin/
There is something like parsedVersion.nextIncrementalVersion
mvn build-helper:parse-version versions:set -DnewVersion=\${parsedVersion.majorVersion}.\${parsedVersion.minorVersion}.\${parsedVersion.nextIncrementalVersion} versions:commit
Looking at this comment you are describing that you are using this version to provide a dependency. maven-release-plugin should help you manage the versions for you. So provide that plugin in your pom.xml.
And for the step of manually providing the release and development version, create a job in jenkins which will have 2 string parameters:
developmentVersion
releaseVersion
Add "Invoke top-level Maven targets" build step to execute the releasing (for example):
clean release:clean release:prepare release:perform -DdevelopmentVersion=${developmentVersion} -DreleaseVersion=${releaseVersion}
When building the job, it will prompt you to insert both the developmentVersion and releaseVersion.
Cheers,
Despot