Configuration
Updatecli must be fed!
Updatecli requires a configuration file, or "manifest", which describes the update pipeline. A manifest describes the "what", the "when", and the "where" of the update pipeline.
What
The "what" is the "source" and defines what piece of information we’re looking for, such as the latest application release version, a docker image tag, etc.
When
The "when" is a "condition", if the condition is satisfied then the target is updated.
Where
The "where" is the "target" and defines where we want to update a piece of information like a value from a Dockerfile or YAML file.
Manifest
File
Each Updatecli pipeline is defined in its own manifest file. The manifest is split into different stages, "source", "conditions", "targets", where every stage relies on a plugin to adapt the behavior.
A file can be of type "yaml" or "Go Template" using file extensions ".yaml",".yml", or ".tpl").
Manifests are given to the updatecli command using the global flag --config <go_template_file> and --values <yaml_file>.
It accepts either a single file or a directory.
If a directory is specified, then it runs recursively on all the go templates (or yaml files) in the directory.
Important | Manifest files starting with an underscore _ are considered as partial files and are not executed. More information on the partial section below. |
Partial
Partials are named, reusable fragments of an Updatecli manifest, typically used to define repeatable logic for:
Scms (e.g., Git repository details)
Sources (e.g., version checks)
Conditions
Targets
These fragments are automatically available to pipelines within the same directory, helping keep your main manifests DRY (Don’t Repeat Yourself) and maintainable.
A partial file must have a filename that starts with an underscore (_). Updatecli never loads these as standalone manifest files.
Important | Partial files are concatenated into the main manifest during execution. If a --- YAML document separator is present, the partial feature will be disabled, as the resulting content would be treated as multiple separate YAML documents. |
<details><summary>updatecli.yaml</summary>
autodiscovery:
groupby: {{ .groupby }}
#{{ if or (.scm.enabled) }}
scmid: default
actionid: default
# {{ end }}
crawlers:
golang/gomod:</details>
<details><summary>_scm.yaml</summary>
# {{ if and (.scm.enabled) ( eq .scm.kind "gitea")) }}
actions:
default:
title: 'deps: bump HUGO to {{ source "hugo" }}'
kind: "gitea/pullrequest"
scmid: "default"
scms:
default:
kind: "gitea"
spec:
user: '{{ .scm.user }}'
# {{ if .scm.email }}
email: '{{ .scm.email }}'
# {{ end }}
owner: '{{ .scm.owner }}'
repository: '{{ .scm.repository }}'
token: '{{ .scm.token }}'
username: '{{ .scm.username }}'
branch: '{{ .scm.branch }}'
# {{ if .scm.url }}
url: '{{ .scm.url }}'
# {{ end }}
# {{ end }}</details>
Content
Using go templates allows us to specify generic values in a different YAML file, using --values.
We then reference those values from each go template.
Updatecli also provides a custom function called requiredEnv to inject an environment variable into the template example, {{ requiredEnv "PATH" }}.
Additionally, all functions from the Sprig template library are available.
More information on Go templates is here.
An example values file can contain:
github:
token: yourGithubToken
That can used in a pipeline manifest as:
sources:
sourceid:
name: Get release version from
kind: githubRelease
spec:
owner: "updatecli"
repository: "updatecli"
token: "{{ .github.token }}"
username: "olblak"
versionfilter:
kind: "latest"
conditions:
conditionID:
name: Test if version exist
kind: <resourceType>
spec:
<resourceTypeSpec>
targets:
targetID:
name: Update version in target1
kind: <resourceType>
spec:
<resourceTypeSpec>