Last year we introduced the Pipeline as Code system, which allows you to define your complete Jenkins Pipeline project — building, testing, staging or deploying, whatever you need — from a Jenkinsfile script right in the same source code repository as your project itself, for compatible SCM systems. With this “marker file” standardized, Jenkins is able to detect buildable branches and automatically create subprojects for them, and even detect buildable repositories within an organization, keeping the configuration inside Jenkins itself to a minimum.
Since then we have found a number of cases where administrators want more power and control over how projects are defined. Particularly of interest to our customers with strict security concerns is the desire to restrict who can define Pipeline script. Large installations are also often designed to service many “tenants” from product teams, where the Jenkins administrator is responsible for quality of service — file retention policies, timeouts, shared agent allocation — and may even need to enforce company-wide policies around project aspects such as use of auditing tools. Or the Jenkins administrators may simply wish to insulate development teams from the need to even consider Jenkins configuration, much less learn Groovy syntax.
For these cases we have built an alternative means of defining Pipelines. The interface is simple at the organization folder level:
(You may also load the definition from SCM, of course.)
This facility opens up the possibility for administrators to define a generic Pipeline script which will apply to any project using a given structure, be it a build tool, framework, Dockerfile, or simply some site-specific list of settings in a YAML file. It is even possible to recognize multiple formats, or define multiple projects for a single repository branch with distinct definitions. When and where desired, the controller script can “escape out” to per-repository Pipeline Groovy code, for example to allow additional Jenkins plugins to be used for reports or notifications at the end of a build, without giving up control of overall build aspects such as timeouts and resource allocation.
The new feature is available to users of CloudBees Jenkins Enterprise in the 1.642.x and newer LTS lines, by updating the CloudBees Pipeline: Templates plugin to version 2.2. Further documentation is available on the CloudBees Network.