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.
Related
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
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.
Today while doing the release of our project, the release:perform command failed in between as our nexus was having intermittent issues. The release command only able to upload one pom file to nexus.
Now, the nexus issue is resolved and I am trying to do the release, it fails as the pom file already exists and its not the snapshot version and we don't have access to nexus so that I can delete that file and start over again.
Is there any way I can pass an argument so that release:perform should continue if the file is already there and ignore this but continue with uploading the rest.
I have looked for options of such type but didn't find anything.
My last resource would be to start the release again, which will bump the version number, but would like to understand if there is any other approach where in I don't need to bump the version.
I am using maven 2.2.1
Here's how I have handled this in the past. The release:perform command does a checkout of the tag from your SCM provider (e.g. SVN). This is done in the target/checkout directory of that project - whatever is there should be an exact copy of the released tag, so it will have the right version number in the pom files etc.
If you move to that directory (target/checkout in the directory where you started the release), you can simply do a mvn deploy there and it should compile and package that version, and then upload it to your Nexus instance.
If you don't have the target/checkout directory, you can check out the Tag created as part of the release:prepare phase from your SCM system to a fresh directory and run mvn deploy there.
Since the tag in your SCM has already been created, the only thing that's left is really compiling, packaging and deploying the release, which is exactly what mvn deploy should do.
If you have provided additional parameters (e.g. for activating profiles) for the build during the call to mvn release:perform, you will have to provide these as well when you run mvn deploy.
Using this approach, your version number will not have to change, it can stay the same, since you're just uploading what has already been tagged as part of mvn release:prepare.
My advice would be for you to request from the admins that the old artifact be removed. You can either re-deploy the code from the tag by checking it out and simply doing
mvn deploy
Or rolling back your release:
mvn release:rollback
And re-doing it as usual.
It is essential to remove the old artifact from the remote repository, if the sizes do not match. Release repositories do not allow the redeployment of artifacts, unless this has been explicitly switched on on the server side.
Furthermore, #nwinkler's answer is also quite good.
I'm using Maven 2.2.1 and I sucessfully ran:
mvn -B release:clean release:prepare
But get the error message:
No SCM URL was provided to perform the release from
when I run:
mvn release:perform
My pom.xml have the scm tags defined correctly:
<scm>
<url>file:///C:/tmp/svnrepo/myproj/trunk</url>
<connection>scm:svn:file:///C:/tmp/svnrepo/myproj/trunk</connection>
<developerConnection>scm:svn:file:///C:/tmp/svnrepo/myproj/trunk</developerConnection>
</scm>
It is possible to rerun a maven release:perform by creating a manually edited release.properties file in the root folder. This file should define these two properties: scm.url and scm.tag. Here a possible example:
scm.url=scm:git:https://github.com/owner/repo.git
scm.tag=v1.0.4
With this file it is possible to redo a release:perform task.
Inspired by this answer.
Looks like I did a mvn -DdryRun=true release:perform and this had deleted the release.properties file from the prepare stage.
So I add the -DconnectionUrl to the command to provide url of the tag
It should work. I had similar problem, but in my case perform failed due to network error and I had to restart it with something like:
mvn release:perform -rf :{ARTIFACT ON WHICH IT FAILED} -DconnectionUrl=scm:svn:{URL TO TAG}
The message
No SCM URL was provided to perform the release from
does not mean the SCM URL in the pom.xml!
There are two kinds of SCM-URLS:
Trunk Folder (for development)
Tag Folder (for tagging the release)
In the pom.xml you specify the trunk-folder-url. What the release:perform require is the tag-folder-url. You can specify the parameter -DconnectionUrl.
Usually you are using prepare and perform in one maven call. Prepare do all preparation stuff and will commit some resources to the version-control-system using the comment [maven-release-plugin] prepare release XXX- BUT NOT ALL FILES ARE COMMITTED! One important file is not committed to the version-control-system, the release.properties. This file is used if you omit the -DconnectionUrl.
The problem occourse while perform because the checkout/commit require the release.properties or the -DconnectionUrl respectivly.
You can either:
Specify the tag-url by using -DconnectionUrl or
Call release:prepare release:perform in one shot to rely on the not-committed release.properties
More informations are here
I got this same exception in our CI automation and it turned out to be due to the fact that target/checkout directory already has a release build. For one of the projects, we had to introduce an improvised maven release perform build between the real maven release:prepare and release:perform steps. As part of improvisation the release tag is checked out to target/checkout and what I noticed is that if this directory is left undeleted, it would cause the release:perform to fail with the No SCM URL was provided to perform the release from error. I don't know if it matters, but we also use -DlocalCheckout=true option.
Simply running mvn release:clean release:prepare first, and then mvn release:perform worked for me.
I tried today to switch our release build so that it uses branches. Before my change, I just did
mvn release:prepare -B -Dusername=$SVN_USER -Dpassword=$SVN_PASSWORD -Dtag=$RELEASE_VERSION -DreleaseVersion=$RELEASE_VERSION -DdevelopmentVersion=$NEXT_DEV_VERSION
mvn release:perform
Now I changed to use
mvn release:branch -B -Dusername=$SVN_USER -Dpassword=$SVN_PASSWORD -DbranchName=$RELEASE_VERSION -DreleaseVersion=$RELEASE_VERSION -DdevelopmentVersion=$NEXT_DEV_VERSION -DautoVersionSubmodules=true -DbranchBase=$SVN_BRANCH_BASE -DdryRun=false -DsuppressCommitBeforeBranch=false -DremoteTagging=false -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false -DupdateWorkingCopyVersions=true -DgenerateBackupPoms=false
then I checked that branch out and tried to perform a release on it. But this does not work, it tells me:
Unable to configure SCM repository: No such provider: 's'
SCM config is:
<scm>
<connection>scm:svn:https://svn2.mycompany.com:8443/svn/polyalert/branches/02_Los_1/releases/0.01.9</connection>
<developerConnection>scm:svn:https://svn2.cmycompany.com:8443/svn/polyalert/branches/02_Los_1/releases/0.01.9</developerConnection>
<url>https://svn2.mycompany.com:8443/svn/polyalert/branches/02_Los_1/releases/0.01.9</url>
</scm>
This url might look a bit strange, but we do not have a default layout and this is a correct branch URL.
This is done with maven 3. I´m not sure if it´s correct to do the release:perform in another location than I did the release:branch, but I don´t have a better idea, specifically because I can not set any release.properties file like it is created with release:prepare. Or would it be necessary to do the release:branch AND the release:prepare? A first try on that did not work and got the same error.
Any suggestions?
Thanks
Michael
After lots of struggle, I found the following approach working:
Ensure that your trunk has definitely correct scm info in the pom.
run mvn release:branch -B -Dusername=$SVN_USER -Dpassword=$SVN_PASSWORD -DbranchName=$RELEASE_VERSION -DreleaseVersion=$RELEASE_VERSION -DdevelopmentVersion=$NEXT_DEV_VERSION -DautoVersionSubmodules=true -DbranchBase=$SVN_BRANCH_BASE -DupdateWorkingCopyVersions=true.
This will create a branch in SVN where all versions are kept like they are in the trunk and will then increase version number in the trunk to $NEXT_DEV_VERSION and commit this as well. Branchbase can be set in the plugin configuration as well (in this case it can be omitted here).
checkout the new-made branch and change into the local branch dir
run mvn release:prepare -B -Dusername=$SVN_USER -Dpassword=$SVN_PASSWORD -Dtag=$RELEASE_VERSION -DreleaseVersion=$RELEASE_VERSION to update the release number in your branch to $RELEASE_VERSION (will be changed locally + commit into the branch by this single command). This command will on top create a release tag.
run mvn release:perform in your local branch dir to start the actual build. This will checkout the tag created in the previous step and build upon this code.