-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
Powered by SuggestiMate -
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
Thanks rtyler, I'll try to help on https://issues.jenkins-ci.org/browse/JENKINS-48304
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.
In my environment the timestamp plugin is definitely installed. This only shows up sometimes and is not 100% failing
Same happened here:
- Jenkins Core: 2.89.4
- Pipeline: declarative 1.2.7
- Timestamper 1.8.9
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
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
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)
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.
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
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!
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
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')
```
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 {
- 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') }
- Discard old builds
stage ('sync')
{ steps
}
stage ('cleanup') { steps
}
stage ('setup') { steps
}
stage('download') { steps
}
stage('prepare') { steps
}
stage ('wait') { steps
}
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)
- Discard old builds
- 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
- Trigger parameterized build on other projects
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())
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?
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.
That is a great catch - I'll get a pr up first thing tomorrow. Thank you very much for nailing that down!
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. =)
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.
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!
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?!
The issue is resolved but not yet released - that's how our JIRA flow goes. The release should be within the next few weeks.
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')
+1 still waiting for the fix as we are intermittently seeing this issue.
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.
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.
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?
"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-48304assigned to abayer and could use any help you've got kupas in reproducing this with a Jenkinsfile.