We're building feature branches into a version 'feature_'. Each feature build will produce the same version. Since these are no releases, I want to deploy the artefacts into the Snapshots repo, but Nexus does not allow versions without 'SNAPSHOT' into the Snapshot repo.
How to configure Nexus to allow any version in a repo?
Solved it by appending '-SNAPSHOT' to the branch version.
It's quite tricky to get Maven in Jenkins to use the right version. The way I solved it now is like this. In the build job configure Git to build the branches origin/feature/*. Then:
In the 'build' section, first thing to do is execute a shell command to construct a file 'env.properties' containing the feature branch version to be used by the Maven build command.
echo BRANCH_VERSION="feature_${GIT_BRANCH##*/}-SNAPSHOT" > env.properties
This uses the GIT_BRANCH environment property of Jenkins. The '##*/' is a Bash Shell Parameter Expansion which strips everything from the parameter value except the part after the last '/' character.
Then use the Environment Injector Plugin to 'inject environment variables' to the build job using the 'env.properties' created in the previous step.
Put 'env.properties' in the 'Properties File Path' field.
Use Maven to build a versioned pom with the correct version using 'Invoke top-level Maven targets':
help:effective-pom -Dbuild.number=${BRANCH_VERSION} -Doutput=versioned-pom.xml. This step is necessary because otherwise the pom in the jar artefact does not contain the correct version causing other problems.
Use another 'Invoke top-level Maven targets' step to do the actual build and deploy using the pom version created in the previous step: -f versioned-pom.xml clean source:jar deploy
That's all folks. If anyone knows a simpler solution, let me know.
This is actually a Maven restriction. You can still use version like feature_x-1.2.3-SNAPSHOT though.
What are you actually trying to achieve though?
Related
I recently upgraded from hudson to jenkins. Since they are practically the same I thought it would be just plug and play. I noticed that when I build my projects my war files are being appended with the SNAPSHOT version instead of just .war. I didn't have this problem in hudson.
Is there a way to globally tell jenkins to use the release war, the one in my target directory, as it's artifact build file or have jenkins, I'm assuming the maven plugin, to not append the SNAPSHOT to the file?
SNAPSHOT is added on purpose. Don't mess with it. Either use bleeding-edge or perform mvn release:prepare release:perform in batch mode from Jenkins.
I am unable to edit pom.xml. Is there a way to define final name of the maven artifact built by Hudson, something like this
<finalName>${project.artifactId}-${project.version}-${timestamp}</finalName>
Since mvn -DfinalName="xxx" on command line does not seem to work.
I am looking for Hudon/Jenkins feature to achieve this as well, or modifying settings.xml in maven repo. Basically any method except editing pom.xml
First, you could have a second build step (execute shell or windows batch) to simply rename the artifacts. Obviously, this will forego the automatic maven module artifacting, but are you using that? If not, just archive the file with post-build actions directly on Jenkins or repository of choice.
Second, the moment you check out the files from SVN, you do have access to modify them in your local workspace. Just don't commit them back to repository.
You could run a regex replace to look for <fileName>.*</filename> and replace with whatever you want.
I use the git-describe maven plugin to replace the POMs <version>${describe}</version> placeholder. mvn deploy needs a custom parameter passed in order for it to properly use the actual git describe value.
I'm now using Jenkins to build the project every time we push to the repo however it too doesn't properly use the actual git-describe value.
The jenkins build artifacts always end named project-${describe}
Are there any suggestions on ways I can customize the file names or force it to use the git-describe result? Otherwise I may be back to manual versioning...
The version property does not allow variable substitution. The first link I found googling this was this SO question.
You'll have to use one of the versioning maven plugins. The maven release plugin is the most popular, but you might find that the versions maven plugin better meets your requirements.
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.
We currently use Maven (v2.2.1) to manage our Java projects, including using release:prepare and release:perform to version our releases.
While this is all pretty simple, I find myself needing to produce the build artifacts from a previous release - is it possible to have maven checkout a given (svn) tag, and build the artifacts from that version?
ie. I have the following tags for a project in SVN:
project-1.0.0
project-1.0.1
project-1.1.0
I would like to build 'project-1.0.1' (or in fact any tag from that project).
Edit:
In order to clarify what I'm trying to do, consider the release:prepare and release:perform goals.
During :prepare and :perform Maven asks what SCM tag should be used for this release, and afterwards creates the tag, checks out the source for this tag into a separate directory in order to produce a sort of cleanroom build of your project.
What I would like to do is actually perform this last part, whereby I supply the SCM tag (on the command line, rather than hard coding it in the pom, as that would not be particularly flexible), and Maven happily goes off to checkout the code and perform a cleanroom build, resulting in the final build artifact, in exactly the same way as release:perform.
You may want to look at bootstrapping a project using maven scm plugin.
By defining a pom, which contains your scm configuration with the specified tag, as well as the desired maven goal, you can checkout a tag of your choice and build the same.
The link contains an example configuration.