RELEASED: Public: 2013-11-21
New features
-
New templates in Folders documentation
Templates may now be placed in folders and are then accessible only by jobs (or other templates) in the same folder or below.
-
CloudBees Internal Ticket: RM-1793
Adding instantiate CLI command.
-
CloudBees Internal Ticket: RM-1793
Adding /instantiate REST API command.
-
New template scripting documentation
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.
-
CloudBees Internal Ticket: RM-1780
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.
-
CloudBees Internal Ticket: RM-1805
Updating a job template’s definition by REST or CLI should reconfigure its instances.
-
CloudBees Internal Ticket: RM-1793
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.
Resolved issues
-
CloudBees Internal Ticket: RM-1885
Update entity instances asynchronously. (Also partly fixes RM-1950 by showing an instance list for folder templates, not only job templates.)
-
New template security documentation
[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.)
-
CloudBees Internal Ticket: RM-346
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.
-
CloudBees Internal Ticket: RM-1508
Ensure we only store one property in a given item.
-
CloudBees Internal Ticket: RM-2081
Verifying that a missing AuxInstance subtype no longer prevents job loading.
Known issues
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 allowlist 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 allowlist 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.
-
CloudBees Internal Ticket: RM-2134
Most CLI/REST commands do not yet support structured data types (such as lists of components or auxiliary models).