Templates may now be placed in folders and are then accessible only by jobs (or other templates) in the same folder or below.
Adding instantiate CLI command.
Adding /instantiate REST API command.
Export useful things from the REST API: basic template information: ID, super type, instantiability; attributes of a template; UI controls used by attributes; template & values for an entity instance.
Added serialize, serializeAll, and serializeOption convenience methods for Groovy transformer.
Pass folder environment variables (from the instance’s folder) to an job (or folder) template transformer.
Updating a job template’s definition by REST or CLI should reconfigure its instances.
When creating a templatized job from XML, set the name attribute and run the transformer automatically.
Minor simplifications to config.xml form of some templates instances.
Added view filter to exclude templates.
Noting another use for the instantiable flag in inline help: to block job templates from being used for new jobs.
Update entity instances asynchronously. (Also partly fixes RM-1950 by showing an instance list for folder templates, not only job templates.)
[RM-1600] Tightened security of Groovy/Jelly transformers (and JEXL computed attributes). You can either run a script in a sandbox (and then an administrator can use a link from Manage Jenkins to approve legitimate API usages), or ask an administrator to approve the whole script. (The sandbox option is available only for Groovy.)
Behave more gracefully when a template is missing (deleted, renamed/moved away, or inaccessible). Not intended to be a full fix of RM-346, just better robustness.
Ensure we only store one property in a given item.
Verifying that a missing AuxInstance subtype no longer prevents job loading.
On first startup with 4.x, any existing templates are moved from $JENKINS_HOME/models// subdirectories to $JENKINS_HOME/jobs// alongside regular jobs. If you reverted to 3.x, you would need to manually move them back.
Also any templates created in folders would not be loadable in 3.x at all.
Templates once in use should not be renamed or moved, as there are no hooks to update jobs (or other templates) referring to them to point to the new location. (This was already true of renames in 3.x, but 4.x adds the possibility of moving a template, or renaming its containing folder.)
Security system is not polished yet. When creating a job fails due to a security failure, in Jenkins prior to 1.541 a stack trace is printed. Initial whitelist for sandbox is very small and typical scripts will need many entries added. UI-based management of approvals is limited (for example you cannot yet edit existing whitelist grants).
The Template/List and Template/Create permissions have been removed without replacement. (In 4.x, access to templates is controlled using regular permissions like Job/Read.) If you save RBAC role definitions (or another authorization strategy’s configuration) while running 4.x, any Template/* permissions will silently be removed from your settings.
You should use CloudBees Folders Plus 2.2 or later to avoid seeing junk in the subitem filter folder property.
Templatized job types are mixed into the general New Job form without any separation or grouping. Similarly for templatized builders and publishers.
Internal changes to UIControl to provide a more uniform API. Only affects implementors of custom controls.
Most CLI/REST commands do not yet support structured data types (such as lists of components or auxiliary models).