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

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

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            rakuda Krzesmir Florek created issue -
            petehayes Peter Hayes added a comment -

            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?

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

            rakuda Krzesmir Florek added a comment - 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.
            aristedes 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 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 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 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?
            petehayes 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).

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

            petehayes 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.
            hshah 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.

            hshah 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.
            dantran dan tran made changes -
            Field Original Value New Value
            Link This issue is related to JENKINS-27723 [ JENKINS-27723 ]
            hshah 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

            hshah 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
            hshah Harsh Shah made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            hshah Harsh Shah added a comment -

            If the core is modified the issue will be solved.

            hshah Harsh Shah added a comment - If the core is modified the issue will be solved.
            hshah Harsh Shah made changes -
            Link This issue depends on JENKINS-20473 [ JENKINS-20473 ]
            hshah Harsh Shah made changes -
            Link This issue depends on JENKINS-20473 [ JENKINS-20473 ]
            hshah Harsh Shah made changes -
            Link This issue depends on JENKINS-27875 [ JENKINS-27875 ]
            dantran dan tran added a comment - see JENKINS-27875
            dantran dan tran made changes -
            Assignee Peter Hayes [ petehayes ]
            Resolution Duplicate [ 3 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            dantran dan tran made changes -
            Link This issue is related to JENKINS-27875 [ JENKINS-27875 ]
            dantran dan tran made changes -
            Link This issue is related to JENKINS-27875 [ JENKINS-27875 ]
            dantran dan tran made changes -
            Link This issue is duplicated by JENKINS-27875 [ JENKINS-27875 ]
            dantran dan tran made changes -
            Link This issue depends on JENKINS-27875 [ JENKINS-27875 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 141339 ] JNJira + In-Review [ 189564 ]

            People

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

              Dates

                Created:
                Updated:
                Resolved: