I would like to have a new version on every commit in the master branch.
Since I'm using gradle to build, I found 2 nice plugins, Release https://github.com/researchgate/gradle-release/issues/273 and Git Versioner https://github.com/passsy/gradle-gitVersioner-plugin.
I would like to manage daily commits with some version like 1.0.0.BuildNumber. This needs to create a tag in Git and push, but also I need to set the project.version tag with the right version because I need it for the springBoot buildInfo (I'm getting the BuildProperties in Spring to know the version I'm executing on).
When I try to run:
gradlew release -Prelease.useAutomaticVersion=true
It always fall back to 0.0.1 version.
I'm just using the default configuration of the plugin and I got lost ...
I still had the old project.version defined and the plugin was defaulting to that one.
Related
I want to automate version and changelog creation from Git commits. So it's basically the same thing as npm standard-version but it's for Maven. So how can I achieve the versioning automatically?
additional information: I want to increase the version at POM file using the Git Commit-lint messages. In npm if you commit features it increases MINOR, and if you commit fix it increases PATCH version automatically at Semantic Versioning and creates a changelog for these changes. I was wondering if there is a similar way for Maven?
I couldn't find a direct way for Maven. However, you can still use standard-version to create the changelog and bump up the version. You have to write a script to make package.json and Maven versions same. I used the Versions Maven Plugin to accomplish it.
mvn versions:set -DnewVersion=%npm_package_version% && mvn versions:commit
I'm trying to create a deploy job in Jenkins. Up until now I was building my artifact via the maven install goal and then deploying it on the application server with a shell script. However, I'd now like to skip the install part and just get the artifact from my nexus repository.
I know there is the maven dependency:get which I can use to retrieve the artifact from the repository but is there any way I can make sure I'll get the latest version without passing it as a build parameter?
You have different options:
1) Use the Repository Connector Plugin. With this plugin, you get an additional "Artifact Resolver" build step, where you can download an artifact from a centrally configured (Manage Jenkins) repository to the workspace of your deploy job (with different options like renaming etc).
If you use the version LATEST, you always get the latest version. Likewise, you can use RELEASE for the latest release version or ranges like [1.0,1.1).
There are two caveats however:
In the newest version of the plugin, LATEST is broken (see https://issues.jenkins-ci.org/browse/JENKINS-20263), so you need to use version 0.8.2 for now).
You should manually fingerprint the downloaded artifact, since this is not automatically done right now.
2) Use dependency:get as suggested, but use LATEST or RELEASE as above. However, I do not think this is a really elegant solution. (if you simply use SNAPSHOTs with the same base version, follow khmarbaise's advice and simply add -U to the commandline)
3) Use the Maven Deployment Linker Plugin plugin, which is a rather elegant alternative, since you can copy artifacts from other jobs like Copy-Artifact, but they are still retrieved from your Artifact repository (thus you do not waste diskspace and time). The largest problem with that plugin is that it currently does not support authentification.
I want to add the new pom version after running mvn release plugin to a file and then commit the changes.
I don't want to add a new pom.
also we thought about adding a new profile but then it will run the build part of the build and we don't want that to happened.
what can we do?
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 am not sure if I am doing something wrong here, or if there is a bug in maven-release-plugin. But when I try to release a version 1.2.1, maven creates a tag with the right version, but the version number set in the tag's pom.xml is set at 1.2 (not 1.2.1 as it should).
This is what I do when I tried to fix a bug in 1.2:
svn cp URL/tags/myapp-1.2 URL/branches/myapp-1.2
edit project.version in URL/branches/myapp-1.2/pom.xml to be 1.2.1-SNAPSHOT (was 1.2)
fix the bug in the source
commit changes
mvn release:prepare
#when asked, use the defaults: release version 1.2.1, next dev version 1.2.2-SNAPSHOT
[INFO] BUILD SUCCESSFUL
OK so far, but if I check out the code in the new tag the version is wrong! URL/tags/myapp-1.2.1/pom.xml has version 1.2, not 1.2.1 as the tag name should suggest. If I just run mvn release:perform now, the new uploaded jar will have its name set to myapp-1.2.jar, overwriting the original in the repository.
I have upped the maven-release-plugin version from 2.0 to 2.1, but with no greater success. I know the thing that causes this error is the part of the process where the plugin does this:
svn --non-interactive copy --file /tmp/maven-scm-2371633.commit --revision 19866 URL/tags/myapp-1.2 URL/tags/myapp-1.2.1
This copies the source from tags/myapp-1.2 to tags/myapp-1.2.1, but this does not contain any changes. Do you agree that it should have copied from branches/myapp-1.2, not the tag?
Is this working for anyone else, and do you see if I am doing anything wrong?
You need to verify if the repository link in your pom is pointing to a branch instead of the trunk.
If that is the case, then you'll get the error. Point it to the trunk, instead.