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
Related
Is there a way to configure a single Jenkins job to perform the release of each newer version of my application?
i.e, I would like to know in detail if it's possible to do the following tasks without any human intervention. I'm using SVN as well as Artifactory.
Branch from the tag to be released
Change the snapshot versions in pom files to release versions (for each dependency defined in pom)
Take release build (EAR)
Deploy it in Weblogic instance.
Prepare release note
Tag the release
Thanks in advance.
It can be fully automated using Multijob plugin (Also with a regular single job, but using Multijob it will be easier and you can use Maven targets instead of some manual shell scripting ).
The workflow starts with:
commit and push to git
hook in git should trigger a job by http POST, so u need to configure your job to accept remote triggering. You can pass the branch name as parameter
job started, cloning the branch (git plugin)
start Maven project to mvn clean install and check unit tests (optional)
start Maven project to mvn release:prepare and mvn release:perform to omit the SNAPSHOT from pom.xml
tag the branch (using shell block and simple git commands)
merge to master branch (optionally)
start Maven project to mvn deploy to deploy to weblogic (weblogic should be configured in ~/.m2/settings.xml as the repository for deploying the artifacts
NOTE: all tasks can be also in 1 job with some shell scripting. the best practices is to use plugins but sometimes you will find it easier to use shell scripting for some tasks.
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.
I want to automate our branching process and for that i am using maven-release-plugin.
Following command is used for branching:
mvn --batch-mode release:branch -DupdateBranchVersions=true
-DupdateWorkingCopyVersions=$MoveWorkingCopyToNextVersion
-DautoVersionSubmodules=true -Darguments="-DskipTests"
-DreleaseVersion=$BranchVersion -DbranchName=$BranchVersion
-DscmCommentPrefix=$ReleaseJira:
-Dusername=$BuildUser -Dpassword=$BuildUserPassword
My problem is that with above command version of pom created in branch is "BranchVersion-SNAPSHOT" while i want pom version in branch should be "BranchVersion" i.e. it should not contain snapshot.
I know this is not standard approach but our current release process will not work if branch contains "SNAPSHOT".
Any suggestions?
If you don't get updateVersionsToSnapshot working could you use the versions plugin afterwards to set the version on the Pom
http://mojo.codehaus.org/versions-maven-plugin/set-mojo.html
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'm looking to release a stand-alone patch without committing it. when i prepare a release for a version i get the following error:[ERROR] fatal: Not a git repository (or any of the parent directories): .git
can i release without committing?
for now, what i'm doing is generate a jar locally and upload it manually as an artifact.
I had the same issue with mercurial. You need to use the -DpushChanges=false argument.
See my anwser to a similar question: link
If you don't want to commit anything to the SCM, I think you should try do to a dry run :
Since the Release Plugin performs a number of operations that change the project, it may be wise to do a dry run before a big release or on a new project. To do this, commit all of your files as if you were about to run a full release and run:
mvn release:prepare -DdryRun=true
This is a parameter of the release:prepare Mojo : dryRun.