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

Restart pipeline from specific stage, after failure

    Details

    • Type: New Feature
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: pipeline
    • Labels:
      None
    • Similar Issues:

      Description

      This feature is unplanned and not actively worked on

      The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the Declarative Pipeline roadmap. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

      For the purpose of clarity, we will not be providing this feature for scripted pipelines.

      After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

      Thanks,
      James Dumay
      Product Manager, CloudBees Inc

      It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

      Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

      Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.

        Attachments

          Issue Links

            Activity

            michaelhuettermann Michael Hüttermann created issue -
            michaelhuettermann Michael Hüttermann made changes -
            Field Original Value New Value
            Description It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.
            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            amuniz Antonio Muñiz made changes -
            Component/s workflow-plugin [ 18820 ]
            Component/s pipeline-stage-view-plugin [ 21139 ]
            amuniz Antonio Muñiz made changes -
            Assignee Antonio Muñiz [ amuniz ]
            Hide
            amuniz Antonio Muñiz added a comment -

            This feature is available in a proprietary plugin by CloudBees, this is the documentation.

            Show
            amuniz Antonio Muñiz added a comment - This feature is available in a proprietary plugin by CloudBees, this is the documentation .
            Hide
            michaelhuettermann Michael Hüttermann added a comment -

            Hi Antonio Muñiz,
            thanks for the hint. I think introducing a "checkpoint" is not necessary, since every single Stage should operate as a checkpoint.
            I'd like to see this in the free Jenkins distribution.

            Show
            michaelhuettermann Michael Hüttermann added a comment - Hi Antonio Muñiz , thanks for the hint. I think introducing a "checkpoint" is not necessary, since every single Stage should operate as a checkpoint. I'd like to see this in the free Jenkins distribution.
            Hide
            jglick Jesse Glick added a comment -

            No current plans to release this feature as OSS.

            Show
            jglick Jesse Glick added a comment - No current plans to release this feature as OSS.
            jglick Jesse Glick made changes -
            Status Open [ 1 ] Resolved [ 5 ]
            Resolution Won't Do [ 10001 ]
            Hide
            jmcollin Jean-Marc Collin added a comment -

            Such a shame... Without this feature, Workflow will NEVER replace "Deployment Pipeline" plugin in a PRODuction environment.
            Pipeline can be wide and slow and restarting a Pipeline entirely at each failure is simply not imaginable in the real life (but only in demos).

            I really don't understand that Cloudbees could be an obstacle to the adoption of Workflow. It never have such a position (for what I'm knowing) in the past.

            Can you please consider re-opening this fundamental issue ?

            Jean-Marc

            Show
            jmcollin Jean-Marc Collin added a comment - Such a shame... Without this feature, Workflow will NEVER replace "Deployment Pipeline" plugin in a PRODuction environment. Pipeline can be wide and slow and restarting a Pipeline entirely at each failure is simply not imaginable in the real life (but only in demos). I really don't understand that Cloudbees could be an obstacle to the adoption of Workflow. It never have such a position (for what I'm knowing) in the past. Can you please consider re-opening this fundamental issue ? Jean-Marc
            jmcollin Jean-Marc Collin made changes -
            Link This issue is duplicated by JENKINS-36813 [ JENKINS-36813 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 169841 ] JNJira + In-Review [ 198709 ]
            Hide
            nnordrum Noah Nordrum added a comment -

            Michael Hüttermann Jean-Marc Collin

            Seems like there's an opportunity to create an OSS plugin that does this. Tweet me if you guys want to work together to make one.

            Noah

            Show
            nnordrum Noah Nordrum added a comment - Michael Hüttermann Jean-Marc Collin Seems like there's an opportunity to create an OSS plugin that does this. Tweet me if you guys want to work together to make one. Noah
            Hide
            jmcollin Jean-Marc Collin added a comment -

            Noah Nordrum I would be with great pleasure but :

            1. i have no time for this,
            2. i never develop a Jenkins Plugin. May be the gap is heavy ?

            Have you an idea of the complexity of such a plugin ?

            Show
            jmcollin Jean-Marc Collin added a comment - Noah Nordrum I would be with great pleasure but : i have no time for this, i never develop a Jenkins Plugin. May be the gap is heavy ? Have you an idea of the complexity of such a plugin ?
            Hide
            anudeeplalam Anudeep Lalam added a comment - - edited

            Antonio Muñiz : The Documentation link is invalid. Can you please share the correct link. Also, proprietary Plug-in is not available in Jenkins. Is that the correct plug-in name? If not can you please share the correct name.

            Show
            anudeeplalam Anudeep Lalam added a comment - - edited Antonio Muñiz : The Documentation link is invalid. Can you please share the correct link. Also, proprietary Plug-in is not available in Jenkins. Is that the correct plug-in name? If not can you please share the correct name.
            Hide
            jp83 Jonathan Phelps added a comment -

            Here are the appropriate links to the Cloudbees Checkpoint feature...

            https://www.cloudbees.com/products/cloudbees-jenkins-platform/enterprise-edition/features/checkpoints-plugin
            https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/chapter-workflow.html?q=checkpoints

            I too would really like to see this as an OSS plugin and agree that fundamentally every stage should operate in this way. It's an obstacle for me trying to develop a flow in pipeline.

            I'll admit that my perspective is slightly different in that I'm coming from a hardware design flow and still in the early phase of investigating and trying out Jenkins for automation. My flow is fairly complex and stages are probably much longer than their typical software counterparts, i.e. hours/days and can't really just start over at the beginning every time. I think this is an important consideration for the Jenkins team to further push into other arenas (like the Embedded use-case on the website). I could see that this should possibly fall under enterprise-level support, however, as a side-note, my experience so far that the pay for executor business model doesn't scale well to our type of compute usage. I realize everybody needs to make money, but at my peon level have a hard time asking management to additionally pay to make use of our servers.

            Show
            jp83 Jonathan Phelps added a comment - Here are the appropriate links to the Cloudbees Checkpoint feature... https://www.cloudbees.com/products/cloudbees-jenkins-platform/enterprise-edition/features/checkpoints-plugin https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/chapter-workflow.html?q=checkpoints I too would really like to see this as an OSS plugin and agree that fundamentally every stage should operate in this way. It's an obstacle for me trying to develop a flow in pipeline. I'll admit that my perspective is slightly different in that I'm coming from a hardware design flow and still in the early phase of investigating and trying out Jenkins for automation. My flow is fairly complex and stages are probably much longer than their typical software counterparts, i.e. hours/days and can't really just start over at the beginning every time. I think this is an important consideration for the Jenkins team to further push into other arenas (like the Embedded use-case on the website). I could see that this should possibly fall under enterprise-level support, however, as a side-note, my experience so far that the pay for executor business model doesn't scale well to our type of compute usage. I realize everybody needs to make money, but at my peon level have a hard time asking management to additionally pay to make use of our servers.
            abayer Andrew Bayer made changes -
            Component/s pipeline-general [ 21692 ]
            abayer Andrew Bayer made changes -
            Component/s workflow-plugin [ 18820 ]
            Hide
            fschroder Federico Schroder added a comment -

            I have to agree with the comments made before. I understand that cloudbees needs to make money, but this might stop many users of the free version from adopting the new pipeline functionality. Seems like two conflicting goals.

            Show
            fschroder Federico Schroder added a comment - I have to agree with the comments made before. I understand that cloudbees needs to make money, but this might stop many users of the free version from adopting the new pipeline functionality. Seems like two conflicting goals.
            Hide
            kmorgan Katherine Morgan added a comment - - edited

            I really really really want this feature. And it is absolutely going to stop me from using the pipeline functionality.

            I just spent a full day implementing my build and deployment process with the pipeline functionality. I have builds that progress through these stages: BUILD > DEV > STAGE > INTEG > PREPROD > PROD. I'm using the 'waiting for input' feature to capture human approval to progress the deployment to the next environment. In testing it, I found that the pipelines would fill my 'build executor status' list whilst they were 'waiting for approval', and would block jenkins from doing any more work. Just not usable.

            If the 'restart a stage' feature existed, I could then deploy any pipeline to any environment, achieving build progression and rollback.

            UPDATE: I've since learnt that I need to move my input to outside of a node, this resolves my blocked executors.

            Show
            kmorgan Katherine Morgan added a comment - - edited I really really really want this feature. And it is absolutely going to stop me from using the pipeline functionality. I just spent a full day implementing my build and deployment process with the pipeline functionality. I have builds that progress through these stages: BUILD > DEV > STAGE > INTEG > PREPROD > PROD. I'm using the 'waiting for input' feature to capture human approval to progress the deployment to the next environment. In testing it, I found that the pipelines would fill my 'build executor status' list whilst they were 'waiting for approval', and would block jenkins from doing any more work. Just not usable. If the 'restart a stage' feature existed, I could then deploy any pipeline to any environment, achieving build progression and rollback. UPDATE: I've since learnt that I need to move my input to outside of a node, this resolves my blocked executors.
            Hide
            jmcollin Jean-Marc Collin added a comment -

            Ideally this plugin should be organized as it is done in DeliveryPlugin: you can group steps into stage, display each steps and stage and add a restart button on each steps and stage.
            Please take a look at the delivery Pipeline link here. I wonder if merging the both pulgin to take the best of each is not the best solution.

            Show
            jmcollin Jean-Marc Collin added a comment - Ideally this plugin should be organized as it is done in DeliveryPlugin: you can group steps into stage, display each steps and stage and add a restart button on each steps and stage. Please take a look at the delivery Pipeline link here . I wonder if merging the both pulgin to take the best of each is not the best solution.
            Hide
            romanp Roman Pickl added a comment -

            This is a show stopper

            Show
            romanp Roman Pickl added a comment - This is a show stopper
            Hide
            caley Caley Goff added a comment -

            Hi, this is a major show stopper for our PRODUCTION workflow.

            Like Katherine I currently use the Job Chained Workflow to move batches from BUILD> DEV> CI> QA> TEST> PROD, I cannot afford to have to restart the pipeline from the beginning with a failure that is somewhere in the chain.

            I've added check points as instructed

            stage('deploy ci'){
                node('windows') {
                    //code block
                }
                checkpoint 'Completed deploy ci'
            }
            
            java.lang.NoSuchMethodError: No such DSL method 'checkpoint' found among steps 
            

            We're running Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06)

            Show
            caley Caley Goff added a comment - Hi, this is a major show stopper for our PRODUCTION workflow. Like Katherine I currently use the Job Chained Workflow to move batches from BUILD> DEV> CI> QA> TEST> PROD, I cannot afford to have to restart the pipeline from the beginning with a failure that is somewhere in the chain. I've added check points as instructed stage( 'deploy ci' ){ node( 'windows' ) { //code block } checkpoint 'Completed deploy ci' } java.lang.NoSuchMethodError: No such DSL method 'checkpoint' found among steps We're running Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06)
            Hide
            jglick Jesse Glick added a comment -

            Caley Goff

            We're running Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06)

            Please file a support ticket with CloudBees rather than discussing the issue here.

            Show
            jglick Jesse Glick added a comment - Caley Goff We're running Jenkins ver. 1.651.3.1 (CloudBees Jenkins Enterprise 16.06) Please file a support ticket with CloudBees rather than discussing the issue here.
            Hide
            mrichar2 Mark R added a comment -

            Why won't this be implemented?

            Show
            mrichar2 Mark R added a comment - Why won't this be implemented?
            Hide
            dantran dan tran added a comment -

            same here, it is very convenient with the build pipeline plugin. Can this be reopened and have user vote?

            Show
            dantran dan tran added a comment - same here, it is very convenient with the build pipeline plugin. Can this be reopened and have user vote?
            Hide
            dantran dan tran added a comment - - edited

            Ah, Jenkins Enterprise supports this feature

            Show
            dantran dan tran added a comment - - edited Ah, Jenkins Enterprise supports this feature
            Hide
            schulzha Hans Schulz added a comment -

            I also don't see how this is resolved.
            CloudBees not releasing their plugin is one thing, but this feature is still desireable in OSS Jenkins.

            Show
            schulzha Hans Schulz added a comment - I also don't see how this is resolved. CloudBees not releasing their plugin is one thing, but this feature is still desireable in OSS Jenkins.
            dantran dan tran made changes -
            Link This issue is blocked by JENKINS-35989 [ JENKINS-35989 ]
            Hide
            zigac Ziga Ciglar added a comment -

            I think this feature is necessary for new pipeline plugin. Otherwise OSS Jenkins staff should recommend to fall back to old "Build Pipeline Plugin".

            Show
            zigac Ziga Ciglar added a comment - I think this feature is necessary for new pipeline plugin. Otherwise OSS Jenkins staff should recommend to fall back to old "Build Pipeline Plugin".
            Hide
            sadiqkhoja Sadiq Khoja added a comment -

            we need this

            Show
            sadiqkhoja Sadiq Khoja added a comment - we need this
            sadiqkhoja Sadiq Khoja made changes -
            Resolution Won't Do [ 10001 ]
            Status Resolved [ 5 ] Reopened [ 4 ]
            Hide
            jglick Jesse Glick added a comment -

            checkpoint is a proprietary feature and will not be implemented in OSS.

            For Declarative Pipelines, in principle you could skip some early stage’s and just start running on a later one, using FlowCopier.

            Show
            jglick Jesse Glick added a comment - checkpoint is a proprietary feature and will not be implemented in OSS. For Declarative Pipelines, in principle you could skip some early stage ’s and just start running on a later one, using FlowCopier .
            jglick Jesse Glick made changes -
            Component/s pipeline-model-definition-plugin [ 21706 ]
            Component/s pipeline [ 21692 ]
            jglick Jesse Glick made changes -
            Status Reopened [ 4 ] Open [ 1 ]
            Hide
            eguess74 eguess74 added a comment -

            For all who wants this feature - there is a workaround:
            Create a "configuration job" that is a parameterized job. Fill it with the parameters that are reflecting the names of stages in the pipeline. for example (STAGE1=run/skip, STAGE2=run/skip)
            Use post build action trigger parameterized build to pass all those stages as parameters to the pipeline job.
            Use conditional build step in pipeline to determine if the step needs to be executed or not. (https://jenkins.io/blog/2017/01/19/converting-conditional-to-pipeline/)
            If the pipeline fails at STAGE2 you can rerun it starting from config job and you can say STAGE1=skip, STAGE2=run

            there are additional benefits as you can always go back to every run and see which parameters were used and so on.

            I hope that helps.

            Show
            eguess74 eguess74 added a comment - For all who wants this feature - there is a workaround: Create a "configuration job" that is a parameterized job. Fill it with the parameters that are reflecting the names of stages in the pipeline. for example (STAGE1=run/skip, STAGE2=run/skip) Use post build action trigger parameterized build to pass all those stages as parameters to the pipeline job. Use conditional build step in pipeline to determine if the step needs to be executed or not. ( https://jenkins.io/blog/2017/01/19/converting-conditional-to-pipeline/ ) If the pipeline fails at STAGE2 you can rerun it starting from config job and you can say STAGE1=skip, STAGE2=run there are additional benefits as you can always go back to every run and see which parameters were used and so on. I hope that helps.
            Hide
            grahamlyons Graham Lyons added a comment -

            We have also been bitten by this and won't be able to adopt the new pipelines.

            A side effect of the stages of the pipeline being tightly coupled in one job if you don't keep a full build history (which is inadvisable as Jenkins becomes incredibly slow) then any failures anywhere in the pipeline will result in older builds being discarded and eventually you'll lose the record of e.g. your last successful deployment to production.

            Show
            grahamlyons Graham Lyons added a comment - We have also been bitten by this and won't be able to adopt the new pipelines. A side effect of the stages of the pipeline being tightly coupled in one job if you don't keep a full build history (which is inadvisable as Jenkins becomes incredibly slow) then any failures anywhere in the pipeline will result in older builds being discarded and eventually you'll lose the record of e.g. your last successful deployment to production.
            Hide
            rgodavarthi Ravi Godavarthi added a comment -

            This is a slap in face for writing all the pipeline code and finding out that its not possible to restart a stage in OSS jenkins. I don't know what to do at this point as the workarounds does not help my case. 

            Show
            rgodavarthi Ravi Godavarthi added a comment - This is a slap in face for writing all the pipeline code and finding out that its not possible to restart a stage in OSS jenkins. I don't know what to do at this point as the workarounds does not help my case. 
            Hide
            pmatignon Patrice Matignon added a comment -

            Agreed, it is a clear blocker for adoption. Especially if you have used the Delivery Pipeline plugin in the past in conjunction with the Rebuild plugin, it worked really nicely.

            Show
            pmatignon Patrice Matignon added a comment - Agreed, it is a clear blocker for adoption. Especially if you have used the Delivery Pipeline plugin in the past in conjunction with the Rebuild plugin, it worked really nicely.
            hrmpw Patrick Wolf made changes -
            Assignee CloudBees Inc. [ cloudbees ]
            hrmpw Patrick Wolf made changes -
            Component/s pipeline [ 21692 ]
            Hide
            mmitche Matthew Mitchell added a comment -

            Would love this too!

            Show
            mmitche Matthew Mitchell added a comment - Would love this too!
            Hide
            giorgiosironi Giorgio Sironi added a comment -

            Would love to be able to pay for this feature, as the full Enterprise offering containing checkpoint is out of reach for me.

            Show
            giorgiosironi Giorgio Sironi added a comment - Would love to be able to pay for this feature, as the full Enterprise offering containing checkpoint is out of reach for me.
            Hide
            emoshaya_cognitoiq Ebrahim Moshaya added a comment -

            This missing feature is the only reason stopping us from using the pipeline plugin. We use the Tikal Multijob plugin which allows us to resume from a phase in the pipeline. We really need Checkpoint to be open sourced in order for us to migrate over to use it. 

            Show
            emoshaya_cognitoiq Ebrahim Moshaya added a comment - This missing feature is the only reason stopping us from using the pipeline plugin. We use the Tikal Multijob plugin which allows us to resume from a phase in the pipeline. We really need Checkpoint to be open sourced in order for us to migrate over to use it. 
            Hide
            mmaglana Mark Maglana added a comment -

            The policy of not releasing the plugin to OSS Jenkins is strange and will contribute to the public's perception that Pipeline is not ready for primetime. Personally, this is frustrating after weeks of advocating Jenkins 2.x and the Pipeline plugin only to find out about this policy which means I'll have to re-do my work.

            Also, while an argument can be made that the Checkpoint functionality is a plugin, it's not a standalone one. It exists because Pipeline exists and because the latter is broken without it. This makes Pipeline a partly open-sourced, partly closed-source product which reminds me of similar projects that have gone down in history as projects we'd rather not remember.

            Show
            mmaglana Mark Maglana added a comment - The policy of not releasing the plugin to OSS Jenkins is strange and will contribute to the public's perception that Pipeline is not ready for primetime. Personally, this is frustrating after weeks of advocating Jenkins 2.x and the Pipeline plugin only to find out about this policy which means I'll have to re-do my work. Also, while an argument can be made that the Checkpoint functionality is a plugin, it's not a standalone one. It exists because Pipeline exists and because the latter is broken without it. This makes Pipeline a partly open-sourced, partly closed-source product which reminds me of similar projects that have gone down in history as projects we'd rather not remember.
            Hide
            orrc Christopher Orr added a comment -

            Mark Maglana: This is something you should take up with CloudBees; this is the open source project issue tracker, which is not affiliated with that company (nor am I).

            If there's something you saw on the Jenkins website or wiki which led you to believe that some sort of checkpointing functionality was built in to the Pipeline suite of plugins, beyond the pause/resume and durability features, please let us know so that we can fix that, until the time that someone decides to work on an open-source solution.

            Show
            orrc Christopher Orr added a comment - Mark Maglana : This is something you should take up with CloudBees; this is the open source project issue tracker, which is not affiliated with that company (nor am I). If there's something you saw on the Jenkins website or wiki which led you to believe that some sort of checkpointing functionality was built in to the Pipeline suite of plugins, beyond the pause/resume and durability features, please let us know so that we can fix that, until the time that someone decides to work on an open-source solution.
            Hide
            mmaglana Mark Maglana added a comment -

            Thanks for the response Christopher Orr. I will do as you suggest. However, I think my comment is still relevant in this issue since the Pipeline plugin is open source and appears to be an official component of this project based on this ticket's metadata. Also, checkpoints are an integral feature of the Pipeline plugin if we are to use it as it is intended (continuous delivery). For example, should a pipeline run fail because of some external service failure (staging environment went down, network latency deteriorated, some n00b with sudo access ran `rm -rf /`, etc) and not because of the build itself, there's no reason to restart the whole thing because then that would be a totally new build!

            As for the documentation, firstly, I want to make it clear that the website and wiki have been awesome resources for me and my team as we learned to use the Pipeline plugin. This speaks volumes to the dedication of the community and maintainers. Despite this very important feature being missing (or at least being made unavailable), Jenkins is still, hands down, the best CI/CD tool out there for me. If I remember correctly, nothing led me to believe that the checkpointing fucntionality was built in. However, it would have been helpful if this product limitation was mentioned in the Pipeline docs.

            Show
            mmaglana Mark Maglana added a comment - Thanks for the response Christopher Orr . I will do as you suggest. However, I think my comment is still relevant in this issue since the Pipeline plugin is open source and appears to be an official component of this project based on this ticket's metadata. Also, checkpoints are an integral feature of the Pipeline plugin if we are to use it as it is intended (continuous delivery). For example, should a pipeline run fail because of some external service failure (staging environment went down, network latency deteriorated, some n00b with sudo access ran `rm -rf /`, etc) and not because of the build itself, there's no reason to restart the whole thing because then that would be a totally new build! As for the documentation, firstly, I want to make it clear that the website and wiki have been awesome resources for me and my team as we learned to use the Pipeline plugin. This speaks volumes to the dedication of the community and maintainers. Despite this very important feature being missing (or at least being made unavailable), Jenkins is still, hands down, the best CI/CD tool out there for me. If I remember correctly, nothing led me to believe that the checkpointing fucntionality was built in. However, it would have been helpful if this product limitation was mentioned in the Pipeline docs.
            Hide
            grahamlyons Graham Lyons added a comment -

            This is solving the problem for me at the moment: http://concourse.ci/

            The pipelines in Jenkins lack a lot of what you would expect from a CI/CD pipeline, beyond just the restarting aspect.

            This is an interesting discussion on the subject:

            https://highops.com/insights/continuous-delivery-pipelines-gocd-vs-jenkins/

             

            Show
            grahamlyons Graham Lyons added a comment - This is solving the problem for me at the moment: http://concourse.ci/ The pipelines in Jenkins lack a lot of what you would expect from a CI/CD pipeline, beyond just the restarting aspect. This is an interesting discussion on the subject: https://highops.com/insights/continuous-delivery-pipelines-gocd-vs-jenkins/  
            hrmpw Patrick Wolf made changes -
            Status Open [ 1 ] In Progress [ 3 ]
            Hide
            hrmpw Patrick Wolf added a comment - - edited

            I'm glad to see the level of interest here. I have withheld comment here until it was official but I'm happy to announce that CloudBees will be be releasing the pipeline-checkpoint plugin to open source in the near future.

            This decision has been coming for some time but we wanted to examine this from all angles before making a final decision. I will post a blog and we will begin moving the code to jenkinsci on Github soon. 

            Show
            hrmpw Patrick Wolf added a comment - - edited I'm glad to see the level of interest here. I have withheld comment here until it was official but I'm happy to announce that CloudBees will be be releasing the pipeline-checkpoint plugin to open source in the near future. This decision has been coming for some time but we wanted to examine this from all angles before making a final decision. I will post a blog and we will begin moving the code to jenkinsci on Github soon. 
            Hide
            rgodavarthi Ravi Godavarthi added a comment -

            I just checked my email and logged in just for saying "Arigatho" Patrick Wolf . This is the best news I've heard in a while. YAY

            Show
            rgodavarthi Ravi Godavarthi added a comment - I just checked my email and logged in just for saying "Arigatho" Patrick Wolf . This is the best news I've heard in a while. YAY
            Hide
            schulzha Hans Schulz added a comment -

            That is great news, thank you!

            Show
            schulzha Hans Schulz added a comment - That is great news, thank you!
            Hide
            jmcollin Jean-Marc Collin added a comment -

            Wonderfull, it is the news I've been waiting for more than one year. Many thanks to Cloudbees for this decision.

             

            Jean-Marc

            Show
            jmcollin Jean-Marc Collin added a comment - Wonderfull, it is the news I've been waiting for more than one year. Many thanks to Cloudbees for this decision.   Jean-Marc
            Hide
            orrc Christopher Orr added a comment -

            Patrick Wolf: Thanks for the update, that's certainly interesting news!

            Everybody else: thanks for your enthusiasm, but please remember that this is an issue tracker, and isn't a suitable place for extended discussions.  Every time you add (or edit) a comment, it currently gets sent to at least 50 people.  If you're interested in updates to this issue, please click "Watch this issue" on the right, rather than commenting here.

            Please take a look at https://jenkins.io/participate/ for more information on the various ways you can participate in the project

            Show
            orrc Christopher Orr added a comment - Patrick Wolf : Thanks for the update, that's certainly interesting news! Everybody else: thanks for your enthusiasm, but please remember that this is an issue tracker, and isn't a suitable place for extended discussions.  Every time you add (or edit) a comment, it currently gets sent to at least 50 people.  If you're interested in updates to this issue, please click "Watch this issue" on the right, rather than commenting here. Please take a look at https://jenkins.io/participate/  for more information on the various ways you can participate in the project
            jenkins_pipeline_blue Sumit Kumar made changes -
            Assignee CloudBees Inc. [ cloudbees ] Sumit Kumar [ jenkins_pipeline_blue ]
            jenkins_pipeline_blue Sumit Kumar made changes -
            Assignee Sumit Kumar [ jenkins_pipeline_blue ] CloudBees Inc. [ cloudbees ]
            Hide
            jenkins_pipeline_blue Sumit Kumar added a comment -

            Do we have a timeline on making checkpoint plugin opensource?

            This is a major blocker for us to adobt Jenkins 2.0 Pipeline.

            We should be able to deploy previous versions to the higher environments i.e. In terms of pipeline, resuming from "Deploy to Dev" stage from an earlier build to proceed to "Deploy to QA" Stage using the respective workspace.

            Show
            jenkins_pipeline_blue Sumit Kumar added a comment - Do we have a timeline on making checkpoint plugin opensource? This is a major blocker for us to adobt Jenkins 2.0 Pipeline. We should be able to deploy previous versions to the higher environments i.e. In terms of pipeline, resuming from "Deploy to Dev" stage from an earlier build to proceed to "Deploy to QA" Stage using the respective workspace.
            Hide
            lesinge Yoh Ann added a comment -

            Agree with Sumit Kumar, major blocker to adopt !

            Show
            lesinge Yoh Ann added a comment - Agree with Sumit Kumar , major blocker to adopt !
            abayer Andrew Bayer made changes -
            Component/s pipeline-model-definition-plugin [ 21706 ]
            Hide
            elzinko Thomas Couderc added a comment -

            I agree, this non-yet-existing-feature is a major blocker for CI/CD in our company. GoCD has this feature free out of the box.

            Show
            elzinko Thomas Couderc added a comment - I agree, this non-yet-existing-feature is a major blocker for CI/CD in our company. GoCD has this feature free out of the box.
            jglick Jesse Glick made changes -
            Link This issue relates to JENKINS-45455 [ JENKINS-45455 ]
            Hide
            sofusalbertsen Sofus Albertsen added a comment -

            Bump on this issue.

            It is over 3 months since the statement that this will become avaliable in the OSS version, but then totally quiet.

            Either things will start happening, or the OSS community needs to prioritize this as a missing feature and re-implement it, which would be insanely stupid if it already works...

            Please Cloudbees, give us at least a timeframe for when this will become publicly avaliable.

             

            Regards

            Sofus

            Show
            sofusalbertsen Sofus Albertsen added a comment - Bump on this issue. It is over 3 months since the statement that this will become avaliable in the OSS version, but then totally quiet. Either things will start happening, or the OSS community needs to prioritize this as a missing feature and re-implement it, which would be insanely stupid if it already works... Please Cloudbees, give us at least a timeframe for when this will become publicly avaliable.   Regards Sofus
            Hide
            jamesdumay James Dumay added a comment -

            Hi there,

            After review of the checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the Declarative Pipeline roadmap. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment.

            Thanks,
            James Dumay
            Product Manager, CloudBees Inc

            Show
            jamesdumay James Dumay added a comment - Hi there, After review of the checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so. The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline ( JENKINS-45455 ) as open source. I have put this feature on the Declarative Pipeline roadmap . I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered. For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment. Thanks, James Dumay Product Manager, CloudBees Inc
            jamesdumay James Dumay made changes -
            Description It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=Improvement on roadmap|titleBGColor=#3878de|titleColor=white}
            This improvement is on the Blue Ocean project roadmap. Check the [roadmap page|https://jenkins.io/projects/blueocean/roadmap/] for updates.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            jamesdumay James Dumay made changes -
            Description {panel:title=Improvement on roadmap|titleBGColor=#3878de|titleColor=white}
            This improvement is on the Blue Ocean project roadmap. Check the [roadmap page|https://jenkins.io/projects/blueocean/roadmap/] for updates.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}
            After review of the checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            jamesdumay James Dumay made changes -
            Description {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}
            After review of the checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            jamesdumay James Dumay made changes -
            Status In Progress [ 3 ] Open [ 1 ]
            jamesdumay James Dumay made changes -
            Description {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines. If you have any questions, please don't hesitate to comment.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            jamesdumay James Dumay made changes -
            Description {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            Thanks,
            James Dumay
            Product Manager, CloudBees Inc
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            jamesdumay James Dumay made changes -
            Assignee CloudBees Inc. [ cloudbees ]
            jamesdumay James Dumay made changes -
            Description {panel:title=This feature is unplanned and not actively being worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            Thanks,
            James Dumay
            Product Manager, CloudBees Inc
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            {panel:title=This feature is unplanned and not actively worked on|titleBGColor=grey|titleColor=white}

            The use case for restarting stages of a Pipeline is an important one and as such we intend to include this feature in Declarative Pipeline (JENKINS-45455) as open source. I have put this feature on the [Declarative Pipeline roadmap|https://jenkins.io/projects/blueocean/roadmap/]. I encourage you to review JENKINS-45455 and leave a comment to ensure that your use case is covered.

            For the purpose of clarity, we will not be providing this feature for scripted pipelines.

            After review of the Checkpoints feature, the CloudBees team have come to the decision that will not be open sourcing Checkpoints. I know we had signalled in this issue that we would be open sourcing this feature and I am sincerely sorry to disappoint those who have been waiting for us to do so.

            Thanks,
            James Dumay
            Product Manager, CloudBees Inc
            {panel}


            It would be fine, and customers ask me for that continuously to have the function to again start a failed pipeline,but not at the very beginning, rather at a stage along the pipeline chain, particularly a stage which failed before during a former run,and the cause of the failure was fixed.

            Maybe I've chosen the wrong "component" for this ticket. Please feel free to adjust accordingly.

            Tested on Jenkins ver. 2.0-beta-1, and its new Pi Pipeline item.
            Hide
            mkobit Mike Kobit added a comment -

            Sad to see this, as we were really looking forward to this feature.

            What is the motivation to only provide this to declarative pipelines and not for scripted pipelines?

            Show
            mkobit Mike Kobit added a comment - Sad to see this, as we were really looking forward to this feature. What is the motivation to only provide this to declarative pipelines and not for scripted pipelines?
            Hide
            jamesdumay James Dumay added a comment -

            Mike Kobit scripted pipeline is extremely open ended. As I wrote on JENKINS-45455 "There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only".

            Show
            jamesdumay James Dumay added a comment - Mike Kobit scripted pipeline is extremely open ended. As I wrote on JENKINS-45455 "There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only".
            Hide
            rgodavarthi Ravi Godavarthi added a comment -

            Declarative Pipeline is so immature and only applicable to applications deployed on few environments. The idea of having a seperate Git repo per application where branches correspond to environments is like forcing people to use Branch per Environment strategy which is completely not applicable where there are multiple environments using the same branch.

            e.g. Application1.git (branches) : dev1, dev2, qa, prod, prodb, reg

            If this is to promote Blueocean which is completely useless when you want to run a set of tasks everyday on 20+ environments translates to creating 20 branches and maintain 20 jenkinsFiles only because CloudBees holds the restart Checkpoint plugin. 

            So basically this is gonna be free for small applications and when it actually comes down to a Production scale complex orchestrations you gotta buy Cloudbees Enterprise version

            This is unfortunate since I've spent hundreds of hours on this and I can't afford to pay for enterprise license only to get this single feature. I guess investing time into making my own checkpoint plugin, even if it is as simple as saving the ``` binding.properties and sh 'env' ``` into a file and loading it at begining of every stage

            Show
            rgodavarthi Ravi Godavarthi added a comment - Declarative Pipeline is so immature and only applicable to applications deployed on few environments. The idea of having a seperate Git repo per application where branches correspond to environments is like forcing people to use Branch per Environment strategy which is completely not applicable where there are multiple environments using the same branch. e.g. Application1.git (branches) : dev1, dev2, qa, prod, prodb, reg If this is to promote Blueocean which is completely useless when you want to run a set of tasks everyday on 20+ environments translates to creating 20 branches and maintain 20 jenkinsFiles only because CloudBees holds the restart Checkpoint plugin.  So basically this is gonna be free for small applications and when it actually comes down to a Production scale complex orchestrations you gotta buy Cloudbees Enterprise version This is unfortunate since I've spent hundreds of hours on this and I can't afford to pay for enterprise license only to get this single feature. I guess investing time into making my own checkpoint plugin, even if it is as simple as saving the ``` binding.properties and sh 'env' ``` into a file and loading it at begining of every stage
            Hide
            schulzha Hans Schulz added a comment -

            Agreeing with what Ravi Godavarthi said.

            Declarative pipelines are very restrictive and unsuitable for our pipelines. We have huge Jenkins libraries (>10k lines of code) which basically build an ecosystem around our development and release environment, and we can't afford to refactor these to fit into declarative pipelines, just to get checkpoints working. This is a huge disappointment after the announcement of Patrick Wolf.

            Show
            schulzha Hans Schulz added a comment - Agreeing with what Ravi Godavarthi said. Declarative pipelines are very restrictive and unsuitable for our pipelines. We have huge Jenkins libraries (>10k lines of code) which basically build an ecosystem around our development and release environment, and we can't afford to refactor these to fit into declarative pipelines, just to get checkpoints working. This is a huge disappointment after the announcement of Patrick Wolf .
            Hide
            tobybro Toby Broyles added a comment -

            My understanding was that scripted pipelines were the way to go due to being unrestricted and more powerful. There was nothing in declarative pipelines that you couldn't do in scripted pipelines but now it sounds like that is not going to be the case? 

             

            I am very sad to to see this.

            Show
            tobybro Toby Broyles added a comment - My understanding was that scripted pipelines were the way to go due to being unrestricted and more powerful. There was nothing in declarative pipelines that you couldn't do in scripted pipelines but now it sounds like that is not going to be the case?    I am very sad to to see this.
            Hide
            adelcast Alejandro del Castillo added a comment -

            I echo the same sentiment. I get that declarative pipelines are meant to be super-easy to use and that's why work on declarative is prioritize. But, for power users it's a problem when something is in declarative and not in scripted, since we prefer the power/freedom that scripted pipelines provide.

            Show
            adelcast Alejandro del Castillo added a comment - I echo the same sentiment. I get that declarative pipelines are meant to be super-easy to use and that's why work on declarative is prioritize. But, for power users it's a problem when something is in declarative and not in scripted, since we prefer the power/freedom that scripted pipelines provide.
            Hide
            ljohnston Lance Johnston added a comment -

            Couldn't agree more with the comments since the "we've changed our minds and we're not gonna open source it" announcement a few days ago.

            The old bait and switch... gotta love it.

            Show
            ljohnston Lance Johnston added a comment - Couldn't agree more with the comments since the "we've changed our minds and we're not gonna open source it" announcement a few days ago. The old bait and switch... gotta love it.
            Hide
            btb3 Martin Ba added a comment - - edited

            James Dumay - so ...

            scripted pipeline is extremely open ended. As I wrote on JENKINS-45455 "There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only".

            ... I'm rather unsure how to interpret this: checkpoint is already implemented, so any reference to "less complexity" is either handwaving, or the checkpoint feature you currently want to us to pay for^[a]^ doesn't work properly.

             

            I'll note, as others, that the inability to have checkpoints in jenkins pipeline makes it pretty much useless to us. (workarounds like https://stackoverflow.com/a/40351693/321013 and other mentioned ones non-withstanding)

            ([a]: I'm fine with you trying to make a buck. It's just that I feel the checkpoint feature is not enterprisey at all - it seems vital for any non-trivial long-running pipeline, also (and maybe especially) for small teams.)

            Show
            btb3 Martin Ba added a comment - - edited James Dumay - so ... scripted pipeline is extremely open ended. As I wrote on JENKINS-45455 "There is less complexity and edge cases needed to be handled by making this functionality a Declarative Pipeline feature only". ... I'm rather unsure how to interpret this: checkpoint is already implemented, so any reference to "less complexity" is either handwaving, or the checkpoint feature you currently want to us to pay for^ [a] ^ doesn't work properly.   I'll note, as others, that the inability to have checkpoints in jenkins pipeline makes it pretty much useless to us. (workarounds like https://stackoverflow.com/a/40351693/321013 and other mentioned ones non-withstanding) ( [a] : I'm fine with you trying to make a buck. It's just that I feel the checkpoint feature is not enterprisey at all - it seems vital for any non-trivial long-running pipeline, also (and maybe especially) for small teams.)
            Hide
            lmende Lorenz Mende added a comment -

            I have to agree Martin, the checkpoint feature seems like a vital function for pipeline workflows.

            We are running jobs which last hours to a day and are hardly to modularize further...

             

            Very disappointing decision.

            Show
            lmende Lorenz Mende added a comment - I have to agree Martin, the checkpoint feature seems like a vital function for pipeline workflows. We are running jobs which last hours to a day and are hardly to modularize further...   Very disappointing decision.
            Hide
            tjj225 Tharun John added a comment -

            It is like one step forward and 2 steps backwards. I understand we all need to make money. But this is a genuine request from the community. We are a small team and don't have powerful machines to rerun tests from the beginning. So we still have not yet adopted the groovy code and still running manual pipelines views to resume jobs. Does anybody have a work around for this problem ?

             

            Show
            tjj225 Tharun John added a comment - It is like one step forward and 2 steps backwards. I understand we all need to make money. But this is a genuine request from the community. We are a small team and don't have powerful machines to rerun tests from the beginning. So we still have not yet adopted the groovy code and still running manual pipelines views to resume jobs. Does anybody have a work around for this problem ?  
            Hide
            nocono Oliver Nocon added a comment - - edited

            We are using a workaround with a custom step within a pipeline library similar to this:

            //restartIt.goovy
            def call(Map parameters = [:], body) {
              def timeoutInSeconds = parameters.get('timeoutInSeconds', 900)
              def restart = true
              while (restart) {
                try {
                  body()
                  restart = false
                } catch (Throwable err) {
                  echo "ERROR occured: ${err}"
                  //optional email notification
                  try {
                    timeout(time: timeoutInSeconds, unit: 'SECONDS') {
                      input message: 'Do you want to restart?', ok: 'Restart'
                    }
                  } catch(e) {
                    restart = false
                    throw err
                  }
                }
              }
            }

            This can the be used like:

            restartIt(timeout:1200) {
              node {
                //here the steps you want to possibly restart
              }
            }

             

            For sure, there are some caveats. For example, you should use a node to not block executors.

            Anyway, it helps us in cases where e.g. deployments sometime fail.

            Maybe it helps you as well ...

             

            Show
            nocono Oliver Nocon added a comment - - edited We are using a workaround with a custom step within a pipeline library similar to this: //restartIt.goovy def call(Map parameters = [:] , body) {   def timeoutInSeconds = parameters.get('timeoutInSeconds', 900)   def restart = true   while (restart) {     try {       body()       restart = false     } catch (Throwable err) {       echo "ERROR occured: ${err}"       //optional email notification       try {         timeout(time: timeoutInSeconds, unit: 'SECONDS') {           input message: 'Do you want to restart?', ok: 'Restart'         }       } catch(e) {         restart = false         throw err       }     }   } } This can the be used like: restartIt(timeout:1200) {   node {     //here the steps you want to possibly restart   } }   For sure, there are some caveats. For example, you should use a node to not block executors. Anyway, it helps us in cases where e.g. deployments sometime fail. Maybe it helps you as well ...  
            cloudbees CloudBees Inc. made changes -
            Remote Link This issue links to "CloudBees Internal CD-244 (Web Link)" [ 19093 ]
            Hide
            cproto Christopher Proto added a comment -

            very misguided decision.  our situation is that we enrolled in the paid Jenkins Team version so we are PAYING customers to Cloudbees AND still don't get access to this very basic feature.  It's really sad and unfair to both customers and the community. Feels like a ripoff

            We're looking into options from workarounds mentioned already to jumping ship from Cloudbees+Jenkins entirely:

            Note that every other CI/CD system offers this very basic functionality out of the box.  It's that basic:

            AWS' offering: https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-retry.html 

            CircleCI: https://circleci.com/docs/2.0/workflows/#rerunning-a-workflow-from-a-failed-job

             

             

             

            Show
            cproto Christopher Proto added a comment - very misguided decision.  our situation is that we enrolled in the paid Jenkins Team version so we are PAYING customers to Cloudbees AND still don't get access to this very basic feature.  It's really sad and unfair to both customers and the community. Feels like a ripoff We're looking into options from workarounds mentioned already to jumping ship from Cloudbees+Jenkins entirely: Note that every other CI/CD system offers this very basic functionality out of the box.  It's that basic: AWS' offering:  https://docs.aws.amazon.com/codepipeline/latest/userguide/actions-retry.html   CircleCI: https://circleci.com/docs/2.0/workflows/#rerunning-a-workflow-from-a-failed-job      
            Hide
            cb_tes_global Constantin Bugneac added a comment -

            +1 Completely agree with comments above - it's a shame that Jenkins lacks this obvious feature. 

            Show
            cb_tes_global Constantin Bugneac added a comment - +1 Completely agree with comments above - it's a shame that Jenkins lacks this obvious feature. 
            Hide
            jmcollin Jean-Marc Collin added a comment -

            One year later and this issue is already open and not done. In time, I switch to gitlab CI and this does the work even if functions are not at same level. 

            Show
            jmcollin Jean-Marc Collin added a comment - One year later and this issue is already open and not done. In time, I switch to gitlab CI and this does the work even if functions are not at same level. 
            Hide
            comscience15 Nat Sr added a comment -

            Is it possible to not only for after failure? Sometime I need to get redo the same stage, for example building a new build and testing until all pass before going to next step

             

            Show
            comscience15 Nat Sr added a comment - Is it possible to not only for after failure? Sometime I need to get redo the same stage, for example building a new build and testing until all pass before going to next step  
            Hide
            jamesdumay James Dumay added a comment -

            The plan is to allow this to work for any previously executed stage

            Show
            jamesdumay James Dumay added a comment - The plan is to allow this to work for any previously executed stage
            Hide
            comscience15 Nat Sr added a comment - - edited

            James Dumay that's nice. Thanks James. Hopefully, we can get it ASAP.

            BTW, I saw this ticket which already has a PR up (https://issues.jenkins-ci.org/browse/JENKINS-45455) which I am not sure if it is the same thing or not but it looks like it will restart a specific stage from "Previous build". Can we restart the same build? Not kick off another build and run the specific stage?

            Ex. 
            1) Executed Stage 1
            2) Executed Stage 2
            3) Re-executed Stage 2
            4) Executed Stage 3 ....... and so on

            Show
            comscience15 Nat Sr added a comment - - edited James Dumay that's nice. Thanks James. Hopefully, we can get it ASAP. BTW, I saw this ticket which already has a PR up ( https://issues.jenkins-ci.org/browse/JENKINS-45455 ) which I am not sure if it is the same thing or not but it looks like it will restart a specific stage from " Previous build ". Can we restart the same build? Not kick off another build and run the specific stage? Ex.  1) Executed Stage 1 2) Executed Stage 2 3) Re-executed Stage 2 4) Executed Stage 3 ....... and so on
            shanexpert28 shan shan made changes -
            Rank Ranked lower

              People

              • Assignee:
                Unassigned
                Reporter:
                michaelhuettermann Michael Hüttermann
              • Votes:
                146 Vote for this issue
                Watchers:
                187 Start watching this issue

                Dates

                • Created:
                  Updated: