Versioned templates
In versioned templates each version must be tagged in by git tag using format v[semantic_version]
, for example, v1.0.0
, v2.0.3
, v1.8.17
. Scaffander will track changes between template versions and is able to apply this changes on your generated projects.
If template Git repository contains at least one version tag, the template is automatically considered as versioned template. Tag format must use semantic versioning with prefix v (for example
v2.0.3
,v1.5.185
,v1.0.1
, etc).
Versioned example
In versioned Dockerfile template, you will “hardcode” base image version in Dockerfile:
Once there is new image version ubi-minimal:8.3
available, you just update the template Dockerfile and tag this change in Git as v1.0.1
.
Since you have new version available, all newly generated projects will use ubi-minimal:8.3
as base image - nothing surprising. But from now all your managed repositories generated with older version v1.0.0
can be updated to v1.0.1
automatically. For example you have 10 projects using older ubi-minimal:8.2
based on template v1.0.0
, once you perform the update to v1.0.1
, all of projects will have updated base image to ubi-minimal:8.3
!
How it works? Scaffander will internally generate patch file for all modified, created, deleted, renamed or moved files. In case of file modification, Scaffander uses special patch algorithm to extract the file changes between 2 versions, other changes (file creation, deletion, rename or move) are trivial. Once the patch is prepared, Scaffander can apply it on all managed repositories using given template.
In our example, Scaffander extract the change from Dockerfile (base image update from version 8.2 to 8.3), then applies the change on selected managed repositories.
Please note that template language parts are not versioned. For example if you use imageVersion
as template variable this way: FROM registry.access.redhat.com/ubi8/ubi-minimal:${imageVersion}
, there is no way for Scaffander to track the imageVersion
change, only “static” parts can be tracked.
Incompatible changes
Incompatible change is change of template language expressions, directives or interpolations. Let say you introduce template variable newVariable
, so you add new line to tepmplate file : This is ${newVariable}
and release it as new template version v1.0.2
. When you want to update projects from v1.0.1
to v1.0.2
, Scaffander doesn’t know newVariable
value and therefore cannot update projects automatically. If such cases, you should always mark incompatible changes by adjusting major template version.
Changing major version of template (for example from
v1.0.0
tov2.0.0
) is considered as incompatible change and Scaffander does not allow to update projects with older major version to new one.
Simple and versioned template comparison
Non‑versioned template | Versioned template | |
---|---|---|
Git branch | master |
every template version must be properly tagged with version tag |
Bulk update support | no | yes |
Using variables and template markup | yes | yes |