Support for job and folder definitions as YAML

[oleg-nenashev]

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

[howcroft]

This feature would be very useful, for several reasons:

• I don't need the JobDSL plugin (outside of this being the only way to create jobs via JCASC - at least documented/readily available)
• I would much rather download the jcasc yaml for the jobs of a running instance than "translate" them into scripts.

Another specific corner-case:

• those of us securing Jenkins via Role-Based strategy can't really use the JobDSL with JCASC. It always fails when loading the JobDSL with a 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