Strategy for maven deploy via a Jenkins job

5
votes

I have a Jenkins job that use maven build goals 'clean package deploy' for the master git branch. However, due to the nexus repo not allowing redeploys, if the Jenkins job runs a second time without the version changing, it will fail with the expected 400 Bad Request error:

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
    org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
    on project common-library: 
Failed to deploy artifacts: Could not transfer artifact 
    net.bacon.common:common-library:pom:1.2.13 from/to bacon-releases 
    (https://maven.bacon.com/nexus/content/repositories/releases): 
Failed to transfer file: 
    https://maven.bacon.com/nexus/content/repositories/releases/net/bacon/common/common-library/1.2.13/common-library-1.2.13.pom. 
Return code is: 400, ReasonPhrase:Bad Request.

Can anyone suggest a different strategy, whereby the deploy goal can run without making the Jenkins job fail?

5
javamavenjenkins
Do you want to deploy a snapshot or a release version? – Puce
you shouldn't run clean package deploy cause during the deploy phase the package phase is running a second time. It looks you didn't notice the life cycle. It's only needed to run clean deploy. If you try to deploy an artifact which has already been deployed you can't run it a second time. For such purposes you should use -SNAPSHOT's instead of releases. – khmarbaise
@puce in this case it's a release version – Streetdaddy
@khmarbaise thanks for the info re: clean package deploy vs clean deploy. I'm aware of the problem with redeploying, so I'm trying to understand when is the appropriate time to run the deploy goal ... bit of a maven n00b, so I'm wondering what more experienced individuals do... – Streetdaddy

5 Answers

4
votes

what we do is automatic snapshot builds. then, the version is automatically incremented.

for release build, we use the maven release plugin and enter the version manually. you can, however, let the release plugin do the work. it will remove the "-SNAPSHOT" build, deploy, and then, for the next release version increment the last digit and append the "-SNAPSHOT" again.

for the distribution management, you can have two repos, one for snapshots and one for releases, with different redeploy settings.

1
votes

We apply a "double action" solution:

  • Increment version
  • Run mvn install
  • Run tests
  • If all passed, we run mvn deploy

This way, we do not try to deploy before we know all passed and we have a unique version deployed every time.

I hope this helps.

0
votes

You should make sure, that each commit on master carries its own version number on the pom file. So you won't have redeploys.

There is a good reason for rejecting the "redeploys": The content of a released version should never change.

If you can't avoid commits for the same version number on master, consider changing the chained jenkins job to "clean install" (stores the artifacts only on the local repository) and create a new job with "clean deploy" that is only started manually.

0
votes

This is an issue for our group as well.

We want maven to attempt a PASSIVE deploy, so if the deploy exists at nexus then it will acceptably move on with SUCCESS ALREADY DEPLOYED, and if the deploy does not exist at nexus, it will upload and deploy with SUCCESS.

We want jenkins to deploy after it builds and passes coverage check, but how to make it so that only the un-deployed will get deployed, and the already-deployed are ignored.

Our solution was a custom script.

0
votes

You can use the release candidate concept. When you start the release you add -RC1 to the version (1.1.0-RC1 for example).

With the next redeploy you are increment the RC number. When the release is finished and you want to generate a new TAG, you only delete the RC for the version. before the TAG creation