Avoid deploying artifacts at the end of release builds

Question

I have a maven job in jenkins. Typically, at the end of the build, artifacts will be deployed to artifactory via the jenkins post build action. But if I build the releases, I get an error message from jenkins in this case. Thus, is it possible to avoid deploying artifacts at the end of the release build.

Let me clarify the error. The goals of maven are "clean installation." I need a post action to deploy to artifactory using "normal" work. If I release this artifact through the M2 Release Plugin, the deployment of relased artifacts will be done by the M2 release module itself. But at the end of the work, the post-action tries to deploy an artifact with an old version of SNAPSHOT, which is not allowed by art.

Answer 1

In the "Maven Release Build" configuration, you can set the "Release Environment Variable" in the advanced mode (by default, IS_M2RELEASEBUILD). Later in the post-bild-action “publish artifacts” action, you can check if this environment variable is set and then the deployment is skipped.

Answer 2

Jenkins M2 release plugin (using the maven-release-Maven plugin). If you created a Maven task (instead of Free Style), then in the Release M2 section in the task settings you will see the goals:

-Dresume=false release:prepare release:perform 

If you replace it with the next release of M2, the plugin will not trigger the deployment-initiated deployment target: complete the default target.

 -Dresume=false release:prepare release:perform -Darguments="-Dmaven.deploy.skip=true" 

In my case, I didn’t want the artifacts to be sent to Artifactory right after the release: fulfill and release: prepare the goals were completed, so it helped. But, although Jenkins’s work has a Post Build action of both “Deploy to Artifactory” for both snapshot and repository release (depending on what type of build you have automatic / manual execution of the build job or by executing Release Maven Release ), it never caused a post-build action.

This may be good in this sense, now I can trigger the deployment using the generated release artifacts in the environment, and if the deployment / some IT tests are successful, I can upload the artifacts to Artifactory. The downside is that if your deployment depends on choosing a new artifact from Artifactory / Nexus (i.e., somewhere in the unfolding logic of the script), then you won’t be able to work until you copy the artifacts from one job to another child task.

In addition, for the purpose of maven deployment, valid / settings are required in the settings.xml or pom.xml parameters, where you specify for each of the above sections that are defined in the section that must match the value of the section defined in the .xml / pom.xml setting .

You can determine / set the value of the section for using the repository without release, which is higher in order (to resolve the artifact) than the snapshot repository, i.e. use libs-alpha-local or libs-stage-local, and then let maven deploy the target to deploy artifacts to Artifactory / Nexus.

Later, after successfully deploying in higher environments (e.g. QA / PRE, etc.), you can transfer the artifact from alpha / stage to libs-release-local.

IS_M2RELEASEBUILD The boolean variable that comes with the M2 Release plugin can be used in the conditional step to deploy here or there or not at all.

Answer 3

I think you can create a separate jenkins work only for your releases. And under the action of post build to run various maven commands only for packaging artificat, and not for installation in artifactory. This suggests that other applications depend on the artifact that you do not want to release. This can cause version issues.

Answer 4

You should take a look at the Artifactory Jenkins plugin. 1. It is deployed with errors. 2. It has built-in release functionality. 3. It will provide you with unique buildInfo functionality to save assembly information that is more rigid with artifacts in Artifactory, https://wiki.jenkins-ci.org/display/JENKINS/Artifactory+Plugin

Answer 5

If I can assume that you are using the M2 Release Plugin , then there is another problem. Skipping deployment after release would be an unnecessary workaround since I saw this work. You should try to fix this because of the root cause. This will help if you can provide more information about the error.