Open oleg-nenashev opened 3 years ago
This feature would be very useful, for several reasons:
Another specific corner-case:
hudson.model.Failure: No Create Permissions!
Maybe its a simple case of adding a "System" user which is what JCASC may be using under the hood, so the JobDSL route works.
Anyway, I'm going to have to dig deep into JCASC/Jenkins source code to understand if I need to add a "system" user of some sort, as the docs I've read have no mention of how this works.A bit more info, I'm using the docker container, and still creating the jobs with custom groovy scripts due to this JCASC behavioural detail:
Processing provided DSL script
INFO j.j.plugin.JenkinsJobManagement#createOrUpdateConfig: createOrUpdateConfig for testjobs
SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed ConfigurationAsCode.init
hudson.model.Failure: No Create Permissions!
at org.jenkinsci.plugins.rolestrategy.RoleBasedProjectNamingStrategy.checkName(RoleBasedProjectNamingStrategy.java:99)
By the way, this issue only happens when restricting (best practice) ProjectNamingStrategy, specifically:
projectNamingStrategy:
roleBased:
forceExistingJobs: false
As we have proven during GSoC 2019, it is possible to define many build steps and properties as YAML: https://github.com/jenkinsci/simple-pull-request-job-plugin . Maybe it is time to add support for YAML definition of folders and jobs to the plugin. We already have JobDSL which supports GroovyDSL definitions inside jenkins.yaml, but a pure YAML definition would have certain advantages, and it would also help to modernize plugins using old data binding frameworks
P.S: I was sure there is already a ticket for that...