3

How can I fail the build if a certain artifact does exist in the repository? The Maven Wagon Plugin has an "exists" goal, but not the opposite.

The reason for my question is as follows.

My Maven project goes through an automated build pipeline, which ends in a release stage. This stage performs an automated release through a mvn deploy -P release, after setting the release version with a mvn versions:set -DremoveSnapshot. The stage is triggered manually (since not every push should result in a release).

The mvn deploy will fail if the artifact to be uploaded is already in the repository. But this failure would come very late, during the last stage of the pipeline, while existence in the repository could be checked much earlier.

In order to get fail-fast behavior I would like to check if the artifact that would be released has not already been uploaded to Nexus. I want to do this in the first stage of the pipeline, which only performs a mvn package -P releasable. Preferably the "releasable" profile would make Maven do this check automatically during the "validate" phase of the default lifecycle.

Rinke
  • 6,095
  • 4
  • 38
  • 55
  • This mean in the end that the version you have in your poms is not correctly updated to not correctly maintained cause failing during the deployment at Nexus means the version you are trying to deploy does already exist? – khmarbaise Aug 19 '17 at 10:31
  • @khmarbaise Yes – Rinke Aug 19 '17 at 11:38
  • Ok So now the question: Why do you have not maintained the version correctly which is implied based on the scenario? – khmarbaise Aug 19 '17 at 12:03
  • @khmarbaise We're working on many components (Maven projects) with many teams. A mistake can be made by one of the ~100 programmers: we're all humans. This question is about fail-fast behavior. – Rinke Aug 19 '17 at 12:25
  • That's not the point. We are talking here about a single project which should be handled correctly by your CI process and not manually..via Jenkins for example...The stage you are talking about should handling the setting of the correct release version and of course setting the next development version as well...and nothing should be needed to be done manually...As a fail fast option I can think about a self implemented maven-enforcer-rule...which checks at the beginning of the build if the release versions (only in case of release version) if it already exists and break the build.. – khmarbaise Aug 19 '17 at 12:29
  • @khmarbaise Letting the build pipeline increase the version number automatically has some pitfalls. The main issue is how to determine whether to bump. Since the release stage is a manual stage it could be that there have been commits and builds since the moment the pipeline was started. These commits could have incremented the major version in which case no increment should be done on the master branch. I'm not saying it can't be done automatically, just that it's not trivial. Since devs have to update the readme after release anyway I decided to go for manual with fail-fast behavior instead. – Rinke Aug 22 '17 at 20:05
  • @khmarbaise Would you like to work your suggestion about a custom enforcer rule into an answer? I would find it very interesting. – Rinke Aug 22 '17 at 20:07
  • I didn't understand the downvote, so I preferred to delete the answer, to avoid adding "noise" to your question. I hope someone has the answer, because I am interested in it! – VonC Aug 26 '17 at 16:32
  • "dependency:get simply puts the artifact in the local repository if it exists. ": exactly: you can add in that first build step a test for the file in your local directory: if the GAV file does not exists, exit from that build step with a non-0 status: that will fail the build. – VonC Aug 26 '17 at 16:34
  • @VonC Pity you deleted your answer! I hadn't accepted because I didn't get it to work yet, probably because I didn't fully understand your solution yet. I hope you or another SO user can provide a solution. – Rinke Aug 26 '17 at 20:04
  • I will try and restore it next Monday. But I publish an answer which gets downvoted, I tend to remove it. – VonC Aug 26 '17 at 20:06

1 Answers1

2

The mvn deploy will fail if the artifact to be uploaded is already in the repository

Note: only if you upload as a "RELEASE", not a "SNAPSHOT".

Your build could check first if that release version exists:

mvn dependency:get -Dartifact=g:a:v -o -DrepoUrl=file://path/to/your/repo

If that gav (group-artifact-version) does exists, then you don't proceed with the rest of the build.

To keep that in a pom.xml, you can use:

dependency:get simply puts the artifact in the local repository if it exists.
I'm not sure how to fail the build from that point, since checking the local repo is not good enough.

You can check if the dependency artifact exists in the local maven repo.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Right, I forgot to mention that the release stage strips the "-SNAPSHOT" part. Thanks for the answer. You say: "... then you don't proceed with the rest of the build." How could that be done? – Rinke Aug 19 '17 at 11:17
  • @Rinke "then you don't proceed with the rest of the build. How could that be done?" By a wrapper (a script you write), which first does that check, then calls the usual maven build only if the check passes. – VonC Aug 19 '17 at 11:22
  • Ah, you mean something like a shell script. Can't it be solved in Maven itself? I would like a profile to handle it in the "validate" phase of the default lifecycle. (I updated my question to state this.) – Rinke Aug 19 '17 at 11:34
  • @Rinke You can make that dependency:get call in the validate phase indeed. See my edited answer. – VonC Aug 19 '17 at 11:45
  • dependency:get simply puts the artifact in the local repository if it exists. I'm not sure how to fail the build from that point, since checking the local repo is not good enough. This is because if for some reason the release artifact would be in the local repository, but _not_ in Nexus (e.g. as the result of a failed release stage of a previous build), then the build should succeed, not fail. – Rinke Aug 26 '17 at 14:29