Status: Open (View Workflow)
Job DSL Plugin 1.68
I'm using Job DSL plugin in order to generate and maintain Jenkins jobs.
When provided with an invalid cron expression, I would expect the following:
Jenkins should fail the build and throw an error when provided with an invalid cron expression.
Jenkins doesn't throw any errors / warnings and creates the job successfully but without the build trigger.
Example of job with an invalid trigger:
The output when generating this job via DSL plugin when running the command :
./gradlew rest -Dpattern="jobs/george.groovy" -DbaseUrl="http://localhost:8080/" -Dusername=username -Dpassword=password
And as a result, the job is created as expected but without a build trigger:
Since Job DSL just generates the config.xml (AFAIUI), I supposed that Jenkins should throw an error up the chain so that it would get caught by the DSL plugin and fail the build.
After all, I'm just trying to get the build to fail or at least notify via logging or something else that the cron expression is invalid, not create the job without it as if nothing happened.
Any help is much appreciated!
- is duplicated by
JENKINS-55261 Errors visible in UI are hidden if you use job-dsl
daspilker would that responsibility of throwing those exceptions be suitable for Jenkins core? Just want to know if the bug report is accurate. Thanks again!
gcimpoies the bug report is OK, but next time don't do screenshot of scripts and build output. Just copy the text into the report.
If the responsibility of throwing those exceptions is suitable for Jenkins core is up to the maintainers, but I think it makes sense in core. TimerTrigger is already throwing an exception, but it seems to get lost somewhere in the XML deserialization process. All related core APIs (e.g. REST API) would benefit from the fix.
Job DSL is just a generator for the configuration XML. It does not do any advanced validation, it's not designed to do that.
Job DSL uses Jenkins API to create or update configurations, specifically ModifiableTopLevelItemGroup#createProjectFromXML and AbstractItem#updateByXml. IMHO these API calls should throw an exception to indicate that the configuration is invalid.