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.
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:
activation profile, activated by a properties.
said property would be set by a first build step (or even before in the lifecycle) call to mvn dependency:get using the maven-dependency-plugin task.
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.
Related
I have created pipelines which will clean, compile, test, & deploy the code every time we update it. But in case of a technical issue/or error I want to add a step which allows me to revert/rollback the "build" or deployment.
Is there a maven command that can be used to revert/rollback builds/deployments?
No.
If you just run clean package, then another clean will erase the results of package, but if you have run install or deploy the artifact is send to the local repository or remote repository. This cannot be "rolled back" by Maven.
The Maven Release Plugin has a rollback goal that rolls back the changes that it made to version control:
version changes in POMs are reverted
created tag is deleted
created branch is deleted
However, this rollback does not delete files that were uploaded to the remote repository! If the remote repository does not allow artifacts with final versions to get deleted or modified, then you would end up with a problem, because your next attempt would fail to re-upload.
The Maven Release Plugin internally uses the Maven Deploy Plugin to upload files, and the latter has an experimental deployAtEnd feature. Unfortunately, I did not manage to get it to work for my build (using the suggestion from this SO comment) - I still had a build in which the Maven Release Plugin uploaded files before exiting with a failure.
Are both the things are doing the something different or not?
As the second one, when you right click on any maven project on eclipse go to Maven and then Update project.
First is pretty much clear that it clean and artifacts from target and generate the artifacts into target and local repository.
In the first case, you start Maven to build a jar/war/ear and install it in your local repository. It is Maven mechanism. It also updates your dependencies through the -U flag.
In the second case, you start a procedure of the m2eclipse plugin that updates you dependencies. It will not write any artifacts to your local repository. It also does not run a full build.
"mvn versions:use-releases (mvn goals)" remove the "SNAPSHOT" word on your dependencies, ONLY / DURING the specific build you've triggered, not modifying or parsing your pom.xml on the repo itself (like gitlab) this could be very helpful when using artifactory release management plugin because this process doesn't allow projects with SNAPSHOT word on pom.xml, however I have tried using the mvn versions:use-releases when doing a release on artifactory release plugin, but the build is failing due to the build read 1st the pom.xml (with snapshot) before executing the mvn goals that will remove the snapshot word, even I tried to put the mvn goals on the alternative maven goals and options under "enable artifactory release management"
is there any way to solve this?
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.
My situation: I have project which contains several Maven modules. I make changes to one of them. Suddenly I find out, that my project is no longer possible to be built because of the errors in other modules. To fix this I need to run SVN UPDATE and rebuilt the project.
My assumption: probably, during the build process of my module some of the artifacts are taken from central repository and have the most newest version, while others are still outdated and taken from my local repo.
A question: I don't want to rebuild my project each time someone updates ANOTHER Maven module. I want to download the already built artefacts from the central repository without rebuilding them by myself. Is it possible?
You can tell Reactor which modules to build. In your case when you only change a single module and want to speed up the build you can pass -pl (Project Location) parameter to maven. For example:
mvn -pl module-with-changes
That will build single module, while taking other dependencies from your local Maven Repository or download from Central (whatever is the latest). That said, if you already ran mvn install for whole project and other artifacts have not been updated in Central repository, then Maven will see your local artifacts as latest and will not re-download them.
Another issue you might get with -pl parameter is when other modules in your project depend on the module that you are building. If there is a problem in dependent module you will not see it by building only the dependency model. To avoid that you can pass -amd (Also Make Dependents). Like this:
mvn -pl module-with-changes -amd
That will trigger the build for module-with-changes + modules that depend on module-with-changes + their dependents.
You can get more info about Reactor parameters from here:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/