If you were going to skip all regular build steps, then why not just create a new job called xxxx-release and use that just for releases?

Well I thought that the whole idea of the release plug-in was to avoid creating jobs (with separate workspace, triggers and other configuration) just for the tasks that happen few times in the life time of a branch, and therefore do not require a fully fledged Jenkins job.

And that's why I'd like to skip the normal build (which is something around mvn clean install) and instead in case of a release do a release build (sth around mvn release:prepare). I just feel it's more clear when I've got builds for all my branches that continuously verify that the branches are fine and within those builds I've got a button to make a release from this specific branch than to have 2 builds for every branch one for release & one for the standard CI build.

This is more or less what the m2release plug-in does, but this one does not offer special pre-/post-release actions that your plug-in offers.

I also would love to see this feature. Really, the only reason the separate M2-release plugin exists is for this purpose. Everything else it does can be easily achieved by this plugin (which is better in lots of other ways: tagging releases, the release portal view, pre-post steps, customisable parameters, etc).

So, all we are looking for is one more setting to allow the regular build step to be overridden. I don't know if that is hard or easy to do in Jenkins plugins, but it would be extremely useful.

I'd like to add another comment to explain this further. I don't care too much if an extra "mvn clean install" runs during the release process. That's just a few wasted CPU cycles. But the real problem is that artifacts created during the regular build are what are then archived by Jenkins. Instead I want the artifacts created by the "release:perform" to be stored not from the regular build. Maven changes the version in the pom during "release:perform" so the builds have different results.

Do you have any other workaround for what I'm trying to do with your plugin?

Are you using a maven project type or free style project type? Can you give me some examples of the pre / post steps that you want to run? It would be a big change to support the maven2 job type and all the job configuration associated with it without actually running the core maven build and using those artifacts.

I use this plugin with a maven2 job type myself. For the pre step, I modified the maven release plugin a bit to just verify that there are no uncommitted changes, verify that there are no snapshot dependencies, and then modify the poms to the release version. The regular build then runs (mvn clean deploy). For the post step, I complete the release by tagging the SCM and changing the poms to a snapshot version. I did this again by customizing the maven release plugin a bit (adding a goal called release:commit).

What you are doing is exactly what I'm trying to do. I can't help think that a huge number of Jenkins users out there would also like to do that.

For me, the post steps are tomcat:deploy (several times to different test and dev environments). And during the release process I run "tomcat:deploy -P staging" to deploy to the staging environment. I've tried using the Jenkins batch plugin for that, but haven't been able to get it working the way I want.

Would it be possible in your plugin to override the "Release goals and options" for the maven2 job type? This jenkins plugin https://github.com/jenkinsci/m2release-plugin does it. I am currently using the m2release-plugin but it has its own set of problems which makes yours preferable apart from this problem. You solved it by modifying the maven plugin. Being able to override the release goals would solve it in a simpler way for the rest of us, unless your maven plugin changes made it into the main Apache Maven project.

Peter, do you have any further thoughts about allowing us to suppress or override the regular build goals for a maven project with this release plugin?

Is that something that it is likely you'll be able to add? It would make such a big different to being able to better support the maven release process.

Sorry for not being responsive. I do something similar to what you do with a post build deploy. I use separate deploy jobs all together that are triggered by the upstream build job. The downstream jobs use the lastSuccessfulBuild perma link or are parameterized and then curl the artifacts from the build job and run the deployment. I wasn't aware that Jenkins will not archive the release artifacts when using the m2release plugin. That may be a problem for us as we convert to use that plugin. I'm sure I'll be investigating this further over the next few weeks or so.

Hi,
Any updates to this issue? I have the same issue and I am trying to customize the plugin to override build goal with the release goal. Here is the link https://issues.jenkins-ci.org/browse/JENKINS-27723.

To remove ambiguity I have added one more field called "release goal" in the configure release settings(see the link) where I add the goals. I am able to work this out but some how it is not overriding the default build goal. It executes the build goal and then the release goal.

I am a newbie to Jenkins would appreciate any help provided.

We found a way to have the jenkins release-plugin to notify Jenkins core to skip the default build
1. Introduce a ‘release build step’, once it is executed and return back to Jenkins core[1] with an instance of Environment [2]
2. Set the return Environment instance to null, or introduce an new flag in the environment class which notifies to override the default build.
3. Jenkins core’s Build.java ( and related concrete class ) skip the default build step base on the status of the return Env instance or the status of the new flag
This means we need help from Jenkins core dev to add new capability in Jenkins core to skip the default build step. Will file an RFE with Jenkins core
Thanks
[1] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Build.java
[2] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Environment.java

If the core is modified the issue will be solved.

see JENKINS-27875