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

timestamps() randomly not recognized as a valid option

    • pipeline-model-definition 1.3.3

      timestamp() is not recognised as a valid option when job is triggered because of cron (If job is triggered manually issue it is not reproducible):

      org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
      WorkflowScript: 8: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, disableConcurrentBuilds, overrideIndexTriggers, skipDefaultCheckout]
      

      I am using the plugin in a Declarative pipeline like that:

      pipeline {
          agent { label 'foo' }
      
          options {
              buildDiscarder(logRotator(daysToKeepStr: '20', numToKeepStr: '100'))
              timestamps()
          }
         
         ...
          
          triggers {
              parameterizedCron('''
                  0 7 * * 1-5 % ENVIRONMENT=bar
              ''')
          }
      
          ...    
      }
      
      

          [JENKINS-48556] timestamps() randomly not recognized as a valid option

          R. Tyler Croy added a comment -

          "Fortunately" this has nothing to do with the parameterized scheduler plugin, but rather appears to have something to do with the Declarative runtime environment.

          I have been following this issue in JENKINS-48304 assigned to abayer and could use any help you've got kupas in reproducing this with a Jenkinsfile.

          R. Tyler Croy added a comment - "Fortunately" this has nothing to do with the parameterized scheduler plugin, but rather appears to have something to do with the Declarative runtime environment. I have been following this issue in JENKINS-48304 assigned to abayer and could use any help you've got kupas in reproducing this with a Jenkinsfile .

          Victor Pascual added a comment - Thanks rtyler , I'll try to help on https://issues.jenkins-ci.org/browse/JENKINS-48304

          Andrew Bayer added a comment -

          kupas - so I can't reproduce this in a unit test or in manual testing. What versions of core and Declarative Pipeline do you have installed?

          Andrew Bayer added a comment - kupas - so I can't reproduce this in a unit test or in manual testing. What versions of core and Declarative Pipeline do you have installed?

          abayer here you have the versions:

          • Jenkins Core LTS 2.89.1
          • Declarative pipeline: 1.2.5

          Sorry for the delay.

          Victor Pascual added a comment - abayer here you have the versions: Jenkins Core LTS 2.89.1 Declarative pipeline: 1.2.5 Sorry for the delay.

          Ygor Almeida added a comment -

          This one requires the Timestamper plugin. 

          Ygor Almeida added a comment - This one requires the Timestamper plugin. 

          R. Tyler Croy added a comment -

          In my environment the timestamp plugin is definitely installed. This only shows up sometimes and is not 100% failing

          R. Tyler Croy added a comment - In my environment the timestamp plugin is definitely installed. This only shows up sometimes and is not 100% failing

          Jakob Oswald added a comment -

          Same happened here:

          • Jenkins Core:  2.89.4
          • Pipeline: declarative 1.2.7
          • Timestamper 1.8.9

          Jakob Oswald added a comment - Same happened here: Jenkins Core:  2.89.4 Pipeline: declarative 1.2.7 Timestamper 1.8.9

          Kyle Leinen added a comment -

          We just saw this on over 15 brand new pipeline builds (new repos in Github with Jenkinsfiles) on a server that was just updated to latest LTS with latest plugins.  It only showed up on the first build, subsequent rebuilds worked as expected.

          Kyle Leinen added a comment - We just saw this on over 15 brand new pipeline builds (new repos in Github with Jenkinsfiles) on a server that was just updated to latest LTS with latest plugins.  It only showed up on the first build, subsequent rebuilds worked as expected.

          Hi abayer

          We happened to notice this very issue today. timestamps()  was not recognized

          Happened for less than 10 minutes and possibly cache clear as mentioned in JIRA comment got things working again. We do not use cron to trigger the builds.

          Versions of Jenkins and plugins:

          * Jenkins core: 2.107.2
          * Pipeline: declarative 1.2.9
          * Timestamper: 1.8.10

          Error:

          Running in Durability level: MAX_SURVIVABILITY
          org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 8: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, skipStagesAfterUnstable] @ line 8, column 9.
                     timestamps()
                     ^
          
          1 error
          
          	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
          	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
          	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
          	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
          	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
          	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
          	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
          	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
          	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
          	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
          	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
          	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
          	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
          	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:325)
          	at hudson.model.ResourceController.execute(ResourceController.java:97)
          	at hudson.model.Executor.run(Executor.java:429)
          Finished: FAILURE

          Thanks

          guru Srinivasamurthy added a comment - Hi abayer We happened to notice this very issue today. timestamps()  was not recognized Happened for less than 10 minutes and possibly cache clear as mentioned in JIRA comment got things working again. We do not use cron to trigger the builds. Versions of Jenkins and plugins: * Jenkins core: 2.107.2 * Pipeline: declarative 1.2.9 * Timestamper: 1.8.10 Error: Running in Durability level: MAX_SURVIVABILITY org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 8: Invalid option type "timestamps" . Valid option types: [authorizationMatrix, buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, skipStagesAfterUnstable] @ line 8, column 9. timestamps() ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at groovy.lang.GroovyShell.parse(GroovyShell.java:700) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:325) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE Thanks

          Same here. We have a Multibranch-Pipeline-Job which is connected to a github repository. If the job is triggered by a change, the issue never occurred.

          BUT: Additional to the github trigger, we have a nightly-job configured, which triggers the build of one branch at 02:00AM (to verify if the build-env still works, even if there is a long time without change to the main branch). We experienced the described issue on those nightly triggered builds three times in May and three times in June.

          All six failed builds were complaining about `timestamps` as invalid option, and two of those failed builds were additionally complaining about the `timeout` option as invalid option.

           

          All the latest versions:
          * Jenkins: 2.127
          * Pipeline: 2.5
          * Pipeline: Declarative: 1.2.9
          * Timestamper: 1.8.10
          * Build Timeout: 1.19

          If you need any more information, feel free to reach out to me.

          KR Michael

           

          Michael Musenbrock added a comment - Same here. We have a Multibranch-Pipeline-Job which is connected to a github repository. If the job is triggered by a change, the issue never occurred. BUT: Additional to the github trigger, we have a nightly-job configured, which triggers the build of one branch at 02:00AM (to verify if the build-env still works, even if there is a long time without change to the main branch). We experienced the described issue on those nightly triggered builds three times in May and three times in June. All six failed builds were complaining about `timestamps` as invalid option, and two of those failed builds were additionally complaining about the `timeout` option as invalid option.   All the latest versions: * Jenkins: 2.127 * Pipeline: 2.5 * Pipeline: Declarative: 1.2.9 * Timestamper: 1.8.10 * Build Timeout: 1.19 If you need any more information, feel free to reach out to me. KR Michael  

          Vineet Naik added a comment -

          We are facing this issue after recently upgrading to jenkins v2.121.2 along with the plugins we are using. As mentioned by others, it can't be reproduced by running the job manually. But on this particular installation of jenkins, we have many periodically scheduled pipeline jobs so it occurs fairly often.

          We're running following versions

          Jenkins: 2.121.2

          Pipeline: 2.5

          Pipeline Declarative: 1.3.1

          Timestamper: 1.8.10

          The exception is the exactly the same as included in a previous comment, but adding again for completeness.

          Started by timer
          Running in Durability level: MAX_SURVIVABILITY
          org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 8: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle, timeout, withCredentials, withEnv, ws] @ line 8, column 7.
                   timestamps()
                   ^
          
          1 error
          
          	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
          	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
          	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
          	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
          	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
          	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
          	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
          	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
          	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
          	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
          	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
          	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
          	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
          	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330)
          	at hudson.model.ResourceController.execute(ResourceController.java:97)
          
          

           

           

          Vineet Naik added a comment - We are facing this issue after recently upgrading to jenkins v2.121.2 along with the plugins we are using. As mentioned by others, it can't be reproduced by running the job manually. But on this particular installation of jenkins, we have many periodically scheduled pipeline jobs so it occurs fairly often. We're running following versions Jenkins: 2.121.2 Pipeline: 2.5 Pipeline Declarative: 1.3.1 Timestamper: 1.8.10 The exception is the exactly the same as included in a previous comment, but adding again for completeness. Started by timer Running in Durability level: MAX_SURVIVABILITY org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 8: Invalid option type "timestamps" . Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, throttle, timeout, withCredentials, withEnv, ws] @ line 8, column 7. timestamps() ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at groovy.lang.GroovyShell.parse(GroovyShell.java:700) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330) at hudson.model.ResourceController.execute(ResourceController.java:97)    

          Sam Park added a comment - - edited
          Running in Durability level: MAX_SURVIVABILITY
           org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
           WorkflowScript: 9: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, skipDefaultCheckout, skipStagesAfterUnstable, withCredentials, ws] @ line 9, column 5.
           timestamps()
           ^
          2 errors
          at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
           at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
           at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
           at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
           at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
           at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
           at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
           at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
           at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
           at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
           at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
           at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
           at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
           at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:325)
           at hudson.model.ResourceController.execute(ResourceController.java:97)
           at hudson.model.Executor.run(Executor.java:429)
           Finished: FAILURE 

           
          Jenkins 2.134
          Pipeline 2.5
          Pipeline Declarative 1.3
          Timestamper 1.8.10

          No changes to the system were made. I simply rebooted it.

          For some more context, we define our jobs in Groovy that then use multibranchPipelineJob to reference an actual Jenkinsfile on each project's repository. We have a job that runs Process Job DSLs to then generate all our jobs on our instance. Maybe that's helpful.

          Sam Park added a comment - - edited Running in Durability level: MAX_SURVIVABILITY org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 9: Invalid option type "timestamps" . Valid option types: [authorizationMatrix, buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, skipDefaultCheckout, skipStagesAfterUnstable, withCredentials, ws] @ line 9, column 5. timestamps() ^ 2 errors at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at groovy.lang.GroovyShell.parse(GroovyShell.java:700) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:325) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE   Jenkins 2.134 Pipeline 2.5 Pipeline Declarative 1.3 Timestamper 1.8.10 No changes to the system were made. I simply rebooted it. For some more context, we define our jobs in Groovy that then use multibranchPipelineJob to reference an actual Jenkinsfile on each project's repository. We have a job that runs Process Job DSLs to then generate all our jobs on our instance. Maybe that's helpful.

          Vadim Kotov added a comment -

           Got the same error on a job that is triggered by Gitlab push hook. After I tried to start it manually, it failed again with the same error message. After 15 minutes it works again.

          Jenkins 2.121.2 (LTS)  

          Pipeline 2.5 
          Pipeline Declarative 1.3.1 
          Timestamper 1.8.10 

           

          Vadim Kotov added a comment -  Got the same error on a job that is triggered by Gitlab push hook. After I tried to start it manually, it failed again with the same error message. After 15 minutes it works again. Jenkins 2.121.2 (LTS)   Pipeline 2.5  Pipeline Declarative 1.3.1  Timestamper 1.8.10   

          Hari Dara added a comment -

          Got identical experience as Vadim. This error suddenly started appearing with no updates and no Jenkins restarts and they were all manually triggered builds. I gave up and after an hour when I retriggered the build this error disappeared. Very mysterious!

          Hari Dara added a comment - Got identical experience as Vadim. This error suddenly started appearing with no updates and no Jenkins restarts and they were all manually triggered builds. I gave up and after an hour when I retriggered the build this error disappeared. Very mysterious!

          John Hall added a comment -

          I get the same issue randomly when Gerrit triggers a build.

          org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 97: Invalid option type "timeout". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, office365ConnectorWebhooks, overrideIndexTriggers, preserveStashes, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, timestamps, waitUntil, withContext, withCredentials, withEnv, ws] @ line 97, column 9.
          timeout(time: maxBuildTimeinMinutes, unit: 'MINUTES')
          ^

          1 error

          at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
          at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
          at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
          at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
          at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
          at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
          at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
          at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
          at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
          at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
          at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
          at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
          at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
          at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330)
          at hudson.model.ResourceController.execute(ResourceController.java:97)
          at hudson.model.Executor.run(Executor.java:429)
          Finished: FAILURE

          John Hall added a comment - I get the same issue randomly when Gerrit triggers a build. org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 97: Invalid option type "timeout". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, office365ConnectorWebhooks, overrideIndexTriggers, preserveStashes, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, timestamps, waitUntil, withContext, withCredentials, withEnv, ws] @ line 97, column 9. timeout(time: maxBuildTimeinMinutes, unit: 'MINUTES') ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at groovy.lang.GroovyShell.parse(GroovyShell.java:700) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE

          got the same problem today. 

          the same build worked before , without having been rebooted , or updates of the jenkins or plugins 

          jenkins 2.1.141

          Pipeline:Declarative : 1.3.2

          timestamper 1.8.10

           

          error : 

          org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 7: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, gitLabConnection, gitlabBuilds, newContainerPerStage, overrideIndexTriggers, preserveStashes, quietPeriod, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, timeout, withCredentials, ws] @ line 7, column 9.
          timestamps()
          ^

          1 error

          at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
          at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085)
          at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603)
          at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581)
          at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558)
          at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
          at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
          at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
          at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
          at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131)
          at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125)
          at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560)
          at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521)
          at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330)
          at hudson.model.ResourceController.execute(ResourceController.java:97)
          at hudson.model.Executor.run(Executor.java:429)
          Finished: FAILURE

          Bart Van Haute added a comment - got the same problem today.  the same build worked before , without having been rebooted , or updates of the jenkins or plugins  jenkins 2.1.141 Pipeline:Declarative : 1.3.2 timestamper 1.8.10   error :  org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 7: Invalid option type "timestamps". Valid option types: [authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, gitLabConnection, gitlabBuilds, newContainerPerStage, overrideIndexTriggers, preserveStashes, quietPeriod, retry, script, skipDefaultCheckout, skipStagesAfterUnstable, timeout, withCredentials, ws] @ line 7, column 9. timestamps() ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310) at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1085) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:603) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:581) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:558) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688) at groovy.lang.GroovyShell.parse(GroovyShell.java:700) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.doParse(CpsGroovyShell.java:131) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:125) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:560) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:521) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:330) at hudson.model.ResourceController.execute(ResourceController.java:97) at hudson.model.Executor.run(Executor.java:429) Finished: FAILURE

          Nitin Surana added a comment - - edited

          Have been working without any issues, suddenly started getting this issue during builds (cron/webhook or manual, all fail)

          ```

          vars/BasePipeline.groovy: 19: Invalid option type "timeout".

          Valid option types: [buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers] @ line 19, column 13. timeout(time: 15, unit: 'MINUTES')

          ```

          Nitin Surana added a comment - - edited Have been working without any issues, suddenly started getting this issue during builds (cron/webhook or manual, all fail) ``` vars/BasePipeline.groovy: 19: Invalid option type "timeout". Valid option types: [buildDiscarder, checkoutToSubdirectory, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers] @ line 19, column 13. timeout(time: 15, unit: 'MINUTES') ```

          Mike Balfour added a comment - - edited

          100% REPRO LISTED BELOW

          I have a way to force a similar variation of this bug:

          • Clean install of Jenkins 2.149 on a Windows box
          • Install the default set of plugins along with Parameterized Trigger
          • Create a new job with the following options:
            • Name:  Test1
            • Type:  Pipeline
            • General:
              • Discard old builds
                • Log Rotation(14, 30)
              • Pipeline script:
                • pipeline { agent any parameters { string(name: 'TEST1', defaultValue: 'test', description: 'test') string(name: 'TEST2', defaultValue: 'test', description: 'test') string(name: 'TEST3', defaultValue: 'test', description: 'test') string(name: 'TEST4', defaultValue: 'test', description: 'test') string(name: 'TEST5', defaultValue: 'test', description: 'test') string(name: 'TEST6', defaultValue: 'test', description: 'test') string(name: 'TEST7', defaultValue: 'test', description: 'test') string(name: 'TEST8', defaultValue: 'test', description: 'test') string(name: 'TEST9', defaultValue: 'test', description: 'test') }

                  options { timestamps() timeout( time: 2, unit: 'HOURS') skipDefaultCheckout() buildDiscarder logRotator( daysToKeepStr: '14', numToKeepStr: '30' ) }stages {

          stage ('sync')
           { steps

          { echo '### Sync code' }

          }
          stage ('cleanup') { steps

          { echo '### Clean up environment' }

          }
          stage ('setup') { steps

          { echo '### Set up environment' }

          }
          stage('download') { steps

          { echo '### Download stuff' }

          }
          stage('prepare') { steps

          { echo '### Prepare stuff' }

          }
          stage ('wait') { steps

          { echo "### Wait a bit" }

          }
          stage ('shutdown') { steps{ echo "### Shutdown" }} }
          post

           { failure

          { echo 'Failed' }

          success { echo 'Succeeded' }
          }
          }

          • Clone the job 9 more times so that you have Test1 - Test10 
          • Create a new job with the following options:
            • Name:  Test-Trigger
            • Type:  Freestyle Project
            • General:
              • Discard old builds
                • Log Rotation(14, 30)
            • Build Triggers:
              • Build Periodically(*/1 * * * *)
            • Post-Build Actions:
              • Trigger parameterized build on other projects
                • Projects to build:  Test1, Test2, Test3, Test4, Test5, Test6, Test7, Test8, Test9, Test10
                • Trigger when build is:  Stable
                • Trigger build without parameters:  X

           

          If you let it run for long enough, you should intermittently get the error.  When the error occurs, all 10 jobs will display it simultaneously, and it will continue to occur for the next 10 minutes.  After that, it will generally start succeeding again for another intermittent period of time.

          If you get impatient and want to force the error to happen, I've had success with the following additional steps:

          • Edit the Test4 job
          • Change the options block in the pipeline script to the following:
            • options { bleah() timestamps() timeout( time: 2, unit: 'HOURS') skipDefaultCheckout() buildDiscarder logRotator( daysToKeepStr: '14', numToKeepStr: '30' ) }
          • Let the jobs keep running.

          The first time Test4 runs, it fails with a similar but legitimate error, saying bleah() can't be found.  However, on the next execution one minute later, all 10 jobs fail with timestamps() missing.  At this point, if you remove bleah(), the jobs will continue to fail for the next 10 minutes and then start succeeding again.  (You need to wait for all 10 jobs to fail before removing bleah())

          Mike Balfour added a comment - - edited 100% REPRO LISTED BELOW I have a way to force a similar variation of this bug: Clean install of Jenkins 2.149 on a Windows box Install the default set of plugins along with Parameterized Trigger Create a new job with the following options: Name:  Test1 Type:  Pipeline General: Discard old builds Log Rotation(14, 30) Pipeline script: pipeline { agent any parameters { string(name: 'TEST1', defaultValue: 'test', description: 'test') string(name: 'TEST2', defaultValue: 'test', description: 'test') string(name: 'TEST3', defaultValue: 'test', description: 'test') string(name: 'TEST4', defaultValue: 'test', description: 'test') string(name: 'TEST5', defaultValue: 'test', description: 'test') string(name: 'TEST6', defaultValue: 'test', description: 'test') string(name: 'TEST7', defaultValue: 'test', description: 'test') string(name: 'TEST8', defaultValue: 'test', description: 'test') string(name: 'TEST9', defaultValue: 'test', description: 'test') } options { timestamps() timeout( time: 2, unit: 'HOURS') skipDefaultCheckout() buildDiscarder logRotator( daysToKeepStr: '14', numToKeepStr: '30' ) }stages { stage ('sync')  { steps { echo '### Sync code' } } stage ('cleanup') { steps { echo '### Clean up environment' } } stage ('setup') { steps { echo '### Set up environment' } } stage('download') { steps { echo '### Download stuff' } } stage('prepare') { steps { echo '### Prepare stuff' } } stage ('wait') { steps { echo "### Wait a bit" } } stage ('shutdown') { steps{ echo "### Shutdown" }} } post  { failure { echo 'Failed' } success { echo 'Succeeded' } } } Clone the job 9 more times so that you have Test1 - Test10  Create a new job with the following options: Name:  Test-Trigger Type:  Freestyle Project General: Discard old builds Log Rotation(14, 30) Build Triggers: Build Periodically(*/1 * * * *) Post-Build Actions: Trigger parameterized build on other projects Projects to build:  Test1, Test2, Test3, Test4, Test5, Test6, Test7, Test8, Test9, Test10 Trigger when build is:  Stable Trigger build without parameters:  X   If you let it run for long enough, you should intermittently get the error.  When the error occurs, all 10 jobs will display it simultaneously, and it will continue to occur for the next 10 minutes.  After that, it will generally start succeeding again for another intermittent period of time. If you get impatient and want to force the error to happen, I've had success with the following additional steps: Edit the Test4 job Change the options block in the pipeline script to the following: options { bleah() timestamps() timeout( time: 2, unit: 'HOURS') skipDefaultCheckout() buildDiscarder logRotator( daysToKeepStr: '14', numToKeepStr: '30' ) } Let the jobs keep running. The first time Test4 runs, it fails with a similar but legitimate error, saying bleah() can't be found.  However, on the next execution one minute later, all 10 jobs fail with timestamps() missing.  At this point, if you remove bleah(), the jobs will continue to fail for the next 10 minutes and then start succeeding again.  (You need to wait for all 10 jobs to fail before removing bleah())

          Mike Balfour added a comment -

          abayer - this appears to still be related to JENKINS-48304.  Given that the error clears up after 10 minutes, the class static LoadingCache instances in Options.groovy definitely seem like the culprit.  It appears like things get in a state where the optionTypeCache somehow has an incomplete list in it, appears valid, and stays that way until it gets stale and gets refreshed 10 minutes later. 

          Random thoughts below, maybe helpful, maybe not...

          While looking through the code the following things seem potentially suspicious.

          Probably not the root cause, but...

          1. In Utils.groovy, populateTypeCache calls ExtensionList.lookup(), but it doesn't first call ExtensionList.ensureLoaded().  I know your change to ModelStepLoader.java is intended to guarantee this doesn't get called until after extensions are loaded, but maybe there's a case where it gets in here before an extension is loaded?
          2. In ModelValidatorImpl.groovy, it calls typeForKey when validating each option, which fetches a new copy of the optionTypeCache every time.  In theory, the cache could change between calls.  Maybe it should call getAllowedOptionTypes once, and then check directly against that when going through the loop, to at least guarantee consistency during the check?

          In the "bleah()" test case I have listed above, I also suspect that there might be some bad exception handling going on, where if Test4 throws an exception while populating the cache, perhaps it exits early but the cache appears to be complete?

          Mike Balfour added a comment - abayer - this appears to still be related to JENKINS-48304 .  Given that the error clears up after 10 minutes, the class static LoadingCache instances in Options.groovy definitely seem like the culprit.  It appears like things get in a state where the optionTypeCache somehow has an incomplete list in it, appears valid, and stays that way until it gets stale and gets refreshed 10 minutes later.  Random thoughts below, maybe helpful, maybe not... While looking through the code the following things seem potentially suspicious. Probably not the root cause, but... In Utils.groovy, populateTypeCache calls ExtensionList.lookup(), but it doesn't first call ExtensionList.ensureLoaded().  I know your change to ModelStepLoader.java is intended to guarantee this doesn't get called until after extensions are loaded, but maybe there's a case where it gets in here before an extension is loaded? In ModelValidatorImpl.groovy, it calls typeForKey when validating each option, which fetches a new copy of the optionTypeCache every time.  In theory, the cache could change between calls.  Maybe it should call getAllowedOptionTypes once, and then check directly against that when going through the loop, to at least guarantee consistency during the check? In the "bleah()" test case I have listed above, I also suspect that there might be some bad exception handling going on, where if Test4 throws an exception while populating the cache, perhaps it exits early but the cache appears to be complete?

          Mike Balfour added a comment -

          abayer : The fix for this bug is to change pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Options.groovy getAllowedOptionTypes() from this:

          static Map<String,String> getAllowedOptionTypes()

          { *Map<String,String> c = propertyTypeCache.get(CACHE_KEY)* c.putAll(getEligibleDeclarativeOptionTypeClasses()) c.putAll(getEligibleWrapperStepClasses()) return c.sort() }

          To this:

          static Map<String,String> getAllowedOptionTypes()

          { *Map<String,String> c = [:]* *c.putAll(propertyTypeCache.get(CACHE_KEY))* c.putAll(getEligibleDeclarativeOptionTypeClasses()) c.putAll(getEligibleWrapperStepClasses()) return c.sort() }

          The problem is that the initial assignment is assigning c to a reference of propertyTypeCache instead of making a copy, which causes the rest of the function to modify propertyTypeCache.  If one job is modifying propertyTypeCache while a second job is refreshing the LoadingCache, the resultant Map gets corrupted and produces incorrect results.  (In extremely rare cases, it's also possible to hit a multiple thread exception instead of a corrupted Map.)  To validate both the problem and the fix, print the contents of propertyTypeCache at the start and the end of the function.  The first time through after a cache refresh, propertyTypeCache will end up with different contents.  Subsequent calls prior to the next cache refresh will have the same result at the start and the end, which will be identical to c.  With the fix, the contents of propertyTypeCache will remain consistent through all function calls.

          Note that the getEligibleWrapperStepClasses() and getEligibleDeclarativeOptionTypeClasses() may have a similar bug, as they are likely returning references to the Map instead of copies.  This doesn't currently cause problems because their only uses are as inputs to putAll(), which makes a copy, but they ought to be validated and fixed to ensure they don't cause problems in the future.

          Mike Balfour added a comment - abayer : The fix for this bug is to change pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/model/Options.groovy getAllowedOptionTypes() from this: static Map<String,String> getAllowedOptionTypes() { *Map<String,String> c = propertyTypeCache.get(CACHE_KEY)* c.putAll(getEligibleDeclarativeOptionTypeClasses()) c.putAll(getEligibleWrapperStepClasses()) return c.sort() } To this: static Map<String,String> getAllowedOptionTypes() { *Map<String,String> c = [:]* *c.putAll(propertyTypeCache.get(CACHE_KEY))* c.putAll(getEligibleDeclarativeOptionTypeClasses()) c.putAll(getEligibleWrapperStepClasses()) return c.sort() } The problem is that the initial assignment is assigning c to a reference of propertyTypeCache instead of making a copy, which causes the rest of the function to modify propertyTypeCache.  If one job is modifying propertyTypeCache while a second job is refreshing the LoadingCache, the resultant Map gets corrupted and produces incorrect results.  (In extremely rare cases, it's also possible to hit a multiple thread exception instead of a corrupted Map.)  To validate both the problem and the fix, print the contents of propertyTypeCache at the start and the end of the function.  The first time through after a cache refresh, propertyTypeCache will end up with different contents.  Subsequent calls prior to the next cache refresh will have the same result at the start and the end, which will be identical to c.  With the fix, the contents of propertyTypeCache will remain consistent through all function calls. Note that the getEligibleWrapperStepClasses() and getEligibleDeclarativeOptionTypeClasses() may have a similar bug, as they are likely returning references to the Map instead of copies.  This doesn't currently cause problems because their only uses are as inputs to putAll(), which makes a copy, but they ought to be validated and fixed to ensure they don't cause problems in the future.

          Andrew Bayer added a comment -

          That is a great catch - I'll get a pr up first thing tomorrow. Thank you very much for nailing that down!

          Andrew Bayer added a comment - That is a great catch - I'll get a pr up first thing tomorrow. Thank you very much for nailing that down!

          Andrew Bayer added a comment -

          PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/294 - any suggestions for how can I test this would be hugely appreciated. =)

          Andrew Bayer added a comment - PR up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/294 - any suggestions for how can I test this would be hugely appreciated. =)

          Mike Balfour added a comment -

          Thanks for turning this around so quickly!

          As for testing suggestions:

          The test I listed above was the best one I found for it when hunting and validating the bug, but it's not a great test.  The test will almost definitely show when it's failing if you let it run for up to 12 hours, but succeeding across 12 hours doesn't definitively prove that it's succeeding.  And, 12 hours is a long time to run a test.  If you go really broad with the test and spawn 100 or 1000 jobs at once, you should increase the odds of hitting the problem.  Unfortunately, because the problem only occurs when the LoadingCache refreshes, it only has a chance of happening on 10-minute boundaries, and even then it's dependent on the exact timing and order of context switching between threads right at that moment, which is why the test can sometimes take hours before failing.

          At the code level, if you added an accessor to getEligiblePropertyTypeClasses(), you could call getEligiblePropertyTypeClasses(), getAllowedOptionTypes(), and then getEligiblePropertyTypeClasses() again and validate that the results didn't change and doesn't match the results of getAllowedOptionTypes().  It's a pretty specific and fast unit test that could be created.  

          Unfortunately, I don't know of any immediate and conclusive tests that can be created just by feeding data in at the system level.  If I did, this would have been significantly easier to find and solve.

           

          Mike Balfour added a comment - Thanks for turning this around so quickly! As for testing suggestions: The test I listed above was the best one I found for it when hunting and validating the bug, but it's not a great test.  The test will almost definitely show when it's failing if you let it run for up to 12 hours, but succeeding across 12 hours doesn't definitively prove that it's succeeding.  And, 12 hours is a long time to run a test.  If you go really broad with the test and spawn 100 or 1000 jobs at once, you should increase the odds of hitting the problem.  Unfortunately, because the problem only occurs when the LoadingCache refreshes, it only has a chance of happening on 10-minute boundaries, and even then it's dependent on the exact timing and order of context switching between threads right at that moment, which is why the test can sometimes take hours before failing. At the code level, if you added an accessor to getEligiblePropertyTypeClasses(), you could call getEligiblePropertyTypeClasses(), getAllowedOptionTypes(), and then getEligiblePropertyTypeClasses() again and validate that the results didn't change and doesn't match the results of getAllowedOptionTypes().  It's a pretty specific and fast unit test that could be created.   Unfortunately, I don't know of any immediate and conclusive tests that can be created just by feeding data in at the system level.  If I did, this would have been significantly easier to find and solve.  

          Andrew Bayer added a comment -

          This'll be fixed in 1.3.3.

          Andrew Bayer added a comment - This'll be fixed in 1.3.3.

          Andrew Bayer added a comment -

          I ended up deciding it was probably too much of a hassle to reproduce in a test, so hey, we'll just go with it. =) Thanks again!

          Andrew Bayer added a comment - I ended up deciding it was probably too much of a hassle to reproduce in a test, so hey, we'll just go with it. =) Thanks again!

          Shiqiang Duan added a comment -

          1.3.3 is still unreleased and all our pipeline build is failing after upgrading to 1.3.2. How come this issue can be marked as resolved?!

          Shiqiang Duan added a comment - 1.3.3 is still unreleased and all our pipeline build is failing after upgrading to 1.3.2. How come this issue can be marked as resolved?!

          Andrew Bayer added a comment -

          The issue is resolved but not yet released - that's how our JIRA flow goes. The release should be within the next few weeks.

          Andrew Bayer added a comment - The issue is resolved but not yet released - that's how our JIRA flow goes. The release should be within the next few weeks.

          yongdao xu added a comment -

           when the fix can be released? we still got similar error from Jenkins 2.121 with groovy 2.54. thanks.

           

          control.MultipleCompilationErrorsException: startup failed:
          WorkflowScript: 4: Invalid option type "timeout". Valid option types: [ansiColor, authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, copyArtifactPermission, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, quietPeriod, skipDefaultCheckout, skipStagesAfterUnstable, withCredentials, ws] @ line 4, column 7.
          timeout(time: 2, unit: 'HOURS')

           

          yongdao xu added a comment -  when the fix can be released? we still got similar error from Jenkins 2.121 with groovy 2.54. thanks.   control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 4: Invalid option type "timeout". Valid option types: [ansiColor, authorizationMatrix, buildDiscarder, catchError, checkoutToSubdirectory, copyArtifactPermission, disableConcurrentBuilds, disableResume, durabilityHint, newContainerPerStage, overrideIndexTriggers, preserveStashes, quietPeriod, skipDefaultCheckout, skipStagesAfterUnstable, withCredentials, ws] @ line 4, column 7. timeout(time: 2, unit: 'HOURS')  

          Josh Woodcock added a comment -

          We are on version 1.3.4.1 now. Is this resolved and released? 

          Josh Woodcock added a comment - We are on version 1.3.4.1 now. Is this resolved and released? 

          +1 still waiting for the fix as we are intermittently seeing this issue.

          Matthias Schulz added a comment - +1 still waiting for the fix as we are intermittently seeing this issue.

          any news?

          Anatoliy Nenashev added a comment - any news?

          Devin Nusbaum added a comment -

          The fix discussed in earlier comments was released in Pipeline: Declarative 1.33, but I have seen reports from users still experiencing the problem even after that fix, so there are probably other similar problems in the codebase somewhere.

          Devin Nusbaum added a comment - The fix discussed in earlier comments was released in Pipeline: Declarative 1.33, but I have seen reports from users still experiencing the problem even after that fix, so there are probably other similar problems in the codebase somewhere.

          Varun Reddy added a comment -

          We are still facing same issue with Jenkins 2.176.2. Is there anything that we need to do? Weird thing in a multibranch one of my development branch options {timestamps()} it works fine. but same repo with a new branch created from the clone of development branch it is failing. 

          Varun Reddy added a comment - We are still facing same issue with Jenkins 2.176.2. Is there anything that we need to do? Weird thing in a multibranch one of my development branch options {timestamps()} it works fine. but same repo with a new branch created from the clone of development branch it is failing. 

          Mohan added a comment - - edited

          Is this only related to timestamps() and gets resolved if we disable the timestamps() in options? Do we have a fix available for this random issue now? 

          Mohan added a comment - - edited Is this only related to timestamps() and gets resolved if we disable the timestamps() in options? Do we have a fix available for this random issue now? 

            Unassigned Unassigned
            kupas Victor Pascual
            Votes:
            18 Vote for this issue
            Watchers:
            42 Start watching this issue

              Created:
              Updated: