Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11120

Add a possiblity to skip/override the normal build in case of a release.

    • Icon: New Feature New Feature
    • Resolution: Duplicate
    • Icon: Major Major
    • release-plugin
    • None

      It'd be really cool to be able to run a special release build instead of the normal one, either by skipping the normal one (and defining the special build in pre-/post-actions) or by overriding it by a defined release actions.

          [JENKINS-11120] Add a possiblity to skip/override the normal build in case of a release.

          aristedes added a comment -

          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.

          aristedes added a comment - 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.

          aristedes added a comment -

          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?

          aristedes added a comment - 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?

          Peter Hayes added a comment -

          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).

          Peter Hayes added a comment - 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).

          aristedes added a comment -

          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.

          aristedes added a comment - 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.

          aristedes added a comment -

          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.

          aristedes added a comment - 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.

          Peter Hayes added a comment -

          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.

          Peter Hayes added a comment - 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.

          Harsh Shah added a comment -

          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.

          Harsh Shah added a comment - 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.

          Harsh Shah added a comment -

          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

          Harsh Shah added a comment - 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

          Harsh Shah added a comment -

          If the core is modified the issue will be solved.

          Harsh Shah added a comment - If the core is modified the issue will be solved.

          dan tran added a comment -

          dan tran added a comment - see JENKINS-27875

            Unassigned Unassigned
            rakuda Krzesmir Florek
            Votes:
            5 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: