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

140 views
Skip to first unread message

jakob.oswald@gmx.net (JIRA)

unread,
Feb 28, 2018, 1:40:03 PM2/28/18
to jenkinsc...@googlegroups.com
Jakob Oswald commented on Bug JENKINS-48556
 
Re: timestamps() randomly not recognized as a valid option

Same happened here:

  • Jenkins Core:  2.89.4
  • Pipeline: declarative 1.2.7
  • Timestamper 1.8.9
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

andrew.bayer@gmail.com (JIRA)

unread,
Apr 12, 2018, 11:46:02 AM4/12/18
to jenkinsc...@googlegroups.com

kleinen@gmail.com (JIRA)

unread,
Apr 27, 2018, 10:04:02 AM4/27/18
to jenkinsc...@googlegroups.com
Kyle Leinen commented on Bug JENKINS-48556
 
Re: timestamps() randomly not recognized as a valid option

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.

gurusrinivasamurthy@gmail.com (JIRA)

unread,
May 29, 2018, 3:08:02 PM5/29/18
to jenkinsc...@googlegroups.com

Hi Andrew Bayer

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

redeamer@gmx.net (JIRA)

unread,
Jun 14, 2018, 5:57:02 AM6/14/18
to jenkinsc...@googlegroups.com

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

 

naikvin@gmail.com (JIRA)

unread,
Jul 28, 2018, 3:39:04 AM7/28/18
to jenkinsc...@googlegroups.com

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)

 

 

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

spark+jenkins@goodrx.com (JIRA)

unread,
Aug 19, 2018, 10:37:02 PM8/19/18
to jenkinsc...@googlegroups.com
Sam Park commented on Bug JENKINS-48556

```


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

spark+jenkins@goodrx.com (JIRA)

unread,
Aug 19, 2018, 10:37:05 PM8/19/18
to jenkinsc...@googlegroups.com
Sam Park edited a comment on Bug JENKINS-48556

spark+jenkins@goodrx.com (JIRA)

unread,
Aug 19, 2018, 10:37:06 PM8/19/18
to jenkinsc...@googlegroups.com
Sam Park edited a comment on Bug JENKINS-48556
``` {code:java}
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 {code}

```
 
Jenkins 2.134
Pipeline 2.5
Pipeline Declarative 1.3
Timestamper 1.8.10

spark+jenkins@goodrx.com (JIRA)

unread,
Aug 19, 2018, 10:38:03 PM8/19/18
to jenkinsc...@googlegroups.com


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

spark+jenkins@goodrx.com (JIRA)

unread,
Aug 20, 2018, 12:28:03 AM8/20/18
to jenkinsc...@googlegroups.com


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.

vkotovv@gmail.com (JIRA)

unread,
Aug 23, 2018, 9:26:04 AM8/23/18
to jenkinsc...@googlegroups.com

 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 

 

haridara@gmail.com (JIRA)

unread,
Aug 29, 2018, 11:47:03 AM8/29/18
to jenkinsc...@googlegroups.com

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!

This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

john.hall@microchip.com (JIRA)

unread,
Sep 4, 2018, 5:35:02 PM9/4/18
to jenkinsc...@googlegroups.com

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

bvanhaute@gmail.com (JIRA)

unread,
Sep 14, 2018, 10:11:05 AM9/14/18
to jenkinsc...@googlegroups.com

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.cool4urchat@gmail.com (JIRA)

unread,
Oct 12, 2018, 8:14:04 PM10/12/18
to jenkinsc...@googlegroups.com

Have been working without any issues, suddenly started getting this issue during builds :

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.cool4urchat@gmail.com (JIRA)

unread,
Oct 12, 2018, 8:14:05 PM10/12/18
to jenkinsc...@googlegroups.com
Nitin Surana edited a comment on Bug JENKINS-48556

nitin.cool4urchat@gmail.com (JIRA)

unread,
Oct 12, 2018, 8:15:02 PM10/12/18
to jenkinsc...@googlegroups.com
Nitin Surana edited a comment on Bug JENKINS-48556
Have been working without any issues, suddenly started getting this issue during builds : (cron/webhook or manual, all fails)

```

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.cool4urchat@gmail.com (JIRA)

unread,
Oct 12, 2018, 8:15:04 PM10/12/18
to jenkinsc...@googlegroups.com
Nitin Surana edited a comment on Bug JENKINS-48556
Have been working without any issues, suddenly started getting this issue during builds (cron/webhook or manual, all fails 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')

```

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 2:29:03 PM10/30/18
to jenkinsc...@googlegroups.com

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

          Unknown macro: { 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.

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 { timestamps() timeout( time: 2, unit: 'HOURS') skipDefaultCheckout() buildDiscarder logRotator( daysToKeepStr: '14', numToKeepStr: '30' ) }

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 2:31:03 PM10/30/18
to jenkinsc...@googlegroups.com
Mike Balfour edited a comment on Bug JENKINS-48556
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
\ {

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

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.

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 2:39:03 PM10/30/18
to jenkinsc...@googlegroups.com

Unknown macro: \
{ steps
{ echo "### Shutdown" }
}
}
post

Unknown macro: \
{ failure

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 2:41:05 PM10/30/18
to jenkinsc...@googlegroups.com
Mike Balfour edited a comment on Bug JENKINS-48556
+*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

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

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 2:51:03 PM10/30/18
to jenkinsc...@googlegroups.com

Andrew Bayer - 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?

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 3:10:05 PM10/30/18
to jenkinsc...@googlegroups.com

mikejmpile@gmail.com (JIRA)

unread,
Oct 30, 2018, 3:10:14 PM10/30/18
to jenkinsc...@googlegroups.com
stage ('shutdown') \{ steps{ echo "### Shutdown" }} }
post

 \{ failure { echo 'Failed' }

mikejmpile@gmail.com (JIRA)

unread,
Nov 6, 2018, 6:24:05 PM11/6/18
to jenkinsc...@googlegroups.com

Andrew Bayer : 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@gmail.com (JIRA)

unread,
Nov 6, 2018, 8:11:02 PM11/6/18
to jenkinsc...@googlegroups.com

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

andrew.bayer@gmail.com (JIRA)

unread,
Nov 7, 2018, 9:21:08 AM11/7/18
to jenkinsc...@googlegroups.com

andrew.bayer@gmail.com (JIRA)

unread,
Nov 7, 2018, 9:21:08 AM11/7/18
to jenkinsc...@googlegroups.com
Andrew Bayer started work on Bug JENKINS-48556
 
Change By: Andrew Bayer
Status: Reopened In Progress

andrew.bayer@gmail.com (JIRA)

unread,
Nov 7, 2018, 9:21:10 AM11/7/18
to jenkinsc...@googlegroups.com

mikejmpile@gmail.com (JIRA)

unread,
Nov 7, 2018, 10:34:03 AM11/7/18
to jenkinsc...@googlegroups.com

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@gmail.com (JIRA)

unread,
Nov 8, 2018, 10:03:05 AM11/8/18
to jenkinsc...@googlegroups.com
 

This'll be fixed in 1.3.3.

Change By: Andrew Bayer
Status: In Review Resolved
Resolution: Fixed

andrew.bayer@gmail.com (JIRA)

unread,
Nov 8, 2018, 11:25:03 AM11/8/18
to jenkinsc...@googlegroups.com
Andrew Bayer commented on Bug JENKINS-48556
 
Re: timestamps() randomly not recognized as a valid option

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!

duanshiqiang1@gmail.com (JIRA)

unread,
Nov 14, 2018, 4:28:05 AM11/14/18
to jenkinsc...@googlegroups.com

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?!

duanshiqiang1@gmail.com (JIRA)

unread,
Nov 14, 2018, 4:28:10 AM11/14/18
to jenkinsc...@googlegroups.com
Shiqiang Duan reopened an issue
 
Change By: Shiqiang Duan
Resolution: Fixed
Status: Resolved Reopened

andrew.bayer@gmail.com (JIRA)

unread,
Nov 14, 2018, 2:46:05 PM11/14/18
to jenkinsc...@googlegroups.com
 

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

Change By: Andrew Bayer
Status: Reopened Fixed but Unreleased
Resolution: Fixed

xuyd@sdu.edu.cn (JIRA)

unread,
Jan 8, 2019, 4:48:06 AM1/8/19
to jenkinsc...@googlegroups.com
yongdao xu commented on Bug JENKINS-48556
 
Re: timestamps() randomly not recognized as a valid option

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

 

joshwoodcock@beagile.biz (JIRA)

unread,
Jan 11, 2019, 6:11:02 PM1/11/19
to jenkinsc...@googlegroups.com

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

schulzm@adobe.com (JIRA)

unread,
Mar 5, 2019, 4:34:03 PM3/5/19
to jenkinsc...@googlegroups.com

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

scifwm@mail.ru (JIRA)

unread,
Jun 4, 2019, 4:09:03 AM6/4/19
to jenkinsc...@googlegroups.com

dnusbaum@cloudbees.com (JIRA)

unread,
Jul 12, 2019, 12:53:03 PM7/12/19
to jenkinsc...@googlegroups.com

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.

dnusbaum@cloudbees.com (JIRA)

unread,
Jul 12, 2019, 12:54:06 PM7/12/19
to jenkinsc...@googlegroups.com
Change By: Devin Nusbaum
Resolution: Fixed
Status: Fixed but Unreleased Reopened

dnusbaum@cloudbees.com (JIRA)

unread,
Jul 12, 2019, 12:54:12 PM7/12/19
to jenkinsc...@googlegroups.com
Devin Nusbaum updated an issue
Change By: Devin Nusbaum
Released As: pipeline-model-definition 1.3.3

varun.devireddy@moodys.com (JIRA)

unread,
Aug 13, 2019, 3:29:05 PM8/13/19
to jenkinsc...@googlegroups.com
Varun Reddy commented on Bug JENKINS-48556
 
Re: timestamps() randomly not recognized as a valid option

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. 

Reply all
Reply to author
Forward
0 new messages