Flux – Image reflector and automation controllers

Flux: Controller Options

Mon, 01 Jan 0001 00:00:00 +0000

To customise the controller options at install time, please see the bootstrap customization guide.

Image automation flags

Name	Type	Description
`--authorized-event-server-spiffe-id`	strings	SPIFFE ID of an event server authorized to receive events from image-automation-controller. Can be repeated. When set, the event recorder uses SPIFFE mTLS.
`--concurrent`	int	The number of concurrent kustomize reconciles. (default 4)
`--default-service-account`	string	Default service account to use for workload identity when not specified in resources.
`--enable-leader-election`	boolean	Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
`--events-addr`	string	The address of the events receiver.
`--health-addr`	string	The address the health endpoint binds to. (default “:9440”)
`--leader-election-lease-duration`	duration	Interval at which non-leader candidates will wait to force acquire leadership (duration string). (default 35s)
`--leader-election-release-on-cancel`	boolean	Defines if the leader should step down voluntarily on controller manager shutdown. (default true)
`--leader-election-renew-deadline`	duration	Duration that the leading controller manager will retry refreshing leadership before giving up (duration string). (default 30s)
`--leader-election-retry-period`	duration	Duration the LeaderElector clients should wait between tries of actions (duration string). (default 5s)
`--log-encoding`	string	Log encoding format. Can be ‘json’ or ‘console’. (default “json”)
`--log-level`	string	Log verbosity level. Can be one of ’trace’, ‘debug’, ‘info’, ’error’. (default “info”)
`--max-retry-delay`	duration	The maximum amount of time for which an object being reconciled will have to wait before a retry. (default 15m0s)
`--metrics-addr`	string	The address the metric endpoint binds to. (default “:8080”)
`--min-retry-delay`	duration	The minimum amount of time for which an object being reconciled will have to wait before a retry. (default 750ms)
`--no-cross-namespace-refs`	boolean	When set to true, references between custom resources are allowed only if the reference and the referee are in the same namespace.
`--ssh-hostkey-algos`	strings	The list of hostkey algorithms to use for ssh connections, arranged from most preferred to the least.
`--ssh-kex-algos`	strings	The list of key exchange algorithms to use for ssh connections, arranged from most preferred to the least.
`--token-cache-max-size`	int	The maximum amount of entries in the LRU cache used for tokens. (default 100, enabled)
`--spiffe-broker-endpoint`	string	The gRPC URL of the SPIFFE Broker endpoint.
`--spiffe-broker-id`	strings	SPIFFE ID of the SPIFFE Broker endpoint. Can be repeated.
`--token-cache-max-duration`	duration	The maximum duration for which a token would be considered unexpired. This is capped at 1h. (default 1h)
`--watch-all-namespaces`	boolean	Watch for custom resources in all namespaces, if set to false it will only watch the runtime namespace. (default true)
`--watch-label-selector`	string	Watch for resources with matching labels e.g. ‘sharding.fluxcd.io/key=shard1’.
`--feature-gates`	mapStringBool	A comma separated list of key=value pairs defining the state of experimental features.

SPIFFE mTLS

When the repeatable flag --authorized-event-server-spiffe-id is set, image-automation-controller acquires an X.509-SVID from the SPIFFE Workload API. The SPIFFE_ENDPOINT_SOCKET environment variable must point to the Workload API socket.

--authorized-event-server-spiffe-id authorizes the given SPIFFE IDs of event servers to which image-automation-controller sends events. When set, the event recorder uses mTLS.

Each flag value is interpreted as follows:

spiffe://<trust domain>/<path> authorizes exactly that SPIFFE ID.
spiffe://<trust domain>/<path>/ (with a trailing slash) authorizes any SPIFFE ID with that path prefix.
spiffe://<trust domain> (without a path) authorizes any SPIFFE ID in that trust domain.

Whenever <trust domain> equals the special value self, image-automation-controller understands it as the trust domain of the controller’s own X509-SVID.

Invalid values cause image-automation-controller to fail at startup.

SPIFFE Broker API

When --spiffe-broker-endpoint and at least one --spiffe-broker-id are set, image-automation-controller acquires an X.509-SVID from the SPIFFE Workload API and uses it to authenticate to the SPIFFE Broker API. The SPIFFE_ENDPOINT_SOCKET environment variable must point to the Workload API socket.

The Broker is used to acquire JWT-SVIDs for object identity when a ServiceAccount sets credential.auth.fluxcd.io/provider to spiffe. The Broker endpoint is a TCP gRPC target, e.g. dns:///spire-server.spire.svc.cluster.local:8443.

Each --spiffe-broker-id value is interpreted like the SPIFFE IDs used by the mTLS flags. Invalid values cause image-automation-controller to fail at startup.

Feature Gates

Name	Default Value	Description
`CacheSecretsAndConfigMaps`	`false`	Configures the caching of Secrets and ConfigMaps by the controller-runtime client. When enabled, it will cache both object types, resulting in increased memory usage and cluster-wide RBAC permissions (list and watch).
`GitAllBranchReferences`	`true`	Enables the download of all branch head references when push branches are configured.
`GitForcePushBranch`	`true`	Enables the use of “force push” when pushing changes to a separate branch. This fixes issues with stale push branches.
`GitPushRetryOnFailure`	`false`	Enables retrying a failed push to the push branch on top of the latest remote state, instead of failing the reconciliation.
`GitSparseCheckout`	`false`	Enables the use of Git sparse checkout to only fetch the path defined in `.spec.update.path` from the repository.

Image reflector flags

Name	Type	Description
`--authorized-event-server-spiffe-id`	strings	SPIFFE ID of an event server authorized to receive events from image-reflector-controller. Can be repeated. When set, the event recorder uses SPIFFE mTLS.
`--concurrent`	int	The number of concurrent kustomize reconciles. (default 4)
`--default-service-account`	string	Default service account to use for workload identity when not specified in resources.
`--enable-leader-election`	boolean	Enable leader election for controller manager. Enabling this will ensure there is only one active controller manager.
`--events-addr`	string	The address of the events receiver.
`--gc-interval`	int	The interval in number of minutes at which the garbage collector will run for the tags database. Zero disables GC. (default 10)
`--health-addr`	string	The address the health endpoint binds to. (default “:9440”)
`--leader-election-lease-duration`	duration	Interval at which non-leader candidates will wait to force acquire leadership (duration string). (default 35s)
`--leader-election-release-on-cancel`	boolean	Defines if the leader should step down voluntarily on controller manager shutdown. (default true)
`--leader-election-renew-deadline`	duration	Duration that the leading controller manager will retry refreshing leadership before giving up (duration string). (default 30s)
`--leader-election-retry-period`	duration	Duration the LeaderElector clients should wait between tries of actions (duration string). (default 5s)
`--log-encoding`	string	Log encoding format. Can be ‘json’ or ‘console’. (default “json”)
`--log-level`	string	Log verbosity level. Can be one of ’trace’, ‘debug’, ‘info’, ’error’. (default “info”)
`--metrics-addr`	string	The address the metric endpoint binds to. (default “:8080”)
`--no-cross-namespace-refs`	boolean	When set to true, references between custom resources are allowed only if the reference and the referee are in the same namespace.
`--requeue-dependency`	duration	The interval at which failing dependencies are reevaluated. (default 30s)
`--storage-compression-threshold`	int	Threshold in KiB for the tags file of a single ImageRepository to make it compressed. Defaults to 64. Requires `FluxStorage` enabled.
`--storage-path`	string	Where to store the persistent database of image metadata. (default “/data”)
`--storage-value-log-file-size`	int	Set the database’s memory mapped value log file size in bytes. Effective memory usage is about two times this size. (default 268435456)
`--token-cache-max-size`	int	The maximum amount of entries in the LRU cache used for tokens. (default 100, enabled)
`--spiffe-broker-endpoint`	string	The gRPC URL of the SPIFFE Broker endpoint.
`--spiffe-broker-id`	strings	SPIFFE ID of the SPIFFE Broker endpoint. Can be repeated.
`--token-cache-max-duration`	duration	The maximum duration for which a token would be considered unexpired. This is capped at 1h. (default 1h)
`--watch-all-namespaces`	boolean	Watch for custom resources in all namespaces, if set to false it will only watch the runtime namespace. (default true)
`--watch-label-selector`	string	Watch for resources with matching labels e.g. ‘sharding.fluxcd.io/key=shard1’.
`--feature-gates`	mapStringBool	A comma separated list of key=value pairs defining the state of experimental features.

SPIFFE mTLS

When the repeatable flag --authorized-event-server-spiffe-id is set, image-reflector-controller acquires an X.509-SVID from the SPIFFE Workload API. The SPIFFE_ENDPOINT_SOCKET environment variable must point to the Workload API socket.

--authorized-event-server-spiffe-id authorizes the given SPIFFE IDs of event servers to which image-reflector-controller sends events. When set, the event recorder uses mTLS.

Each flag value is interpreted as follows:

spiffe://<trust domain>/<path> authorizes exactly that SPIFFE ID.
spiffe://<trust domain>/<path>/ (with a trailing slash) authorizes any SPIFFE ID with that path prefix.
spiffe://<trust domain> (without a path) authorizes any SPIFFE ID in that trust domain.

Whenever <trust domain> equals the special value self, image-reflector-controller understands it as the trust domain of the controller’s own X509-SVID.

Invalid values cause image-reflector-controller to fail at startup.

SPIFFE Broker API

When --spiffe-broker-endpoint and at least one --spiffe-broker-id are set, image-reflector-controller acquires an X.509-SVID from the SPIFFE Workload API and uses it to authenticate to the SPIFFE Broker API. The SPIFFE_ENDPOINT_SOCKET environment variable must point to the Workload API socket.

Each --spiffe-broker-id value is interpreted like the SPIFFE IDs used by the mTLS flags. Invalid values cause image-reflector-controller to fail at startup.

Feature Gates

Name	Default Value	Description
`CacheSecretsAndConfigMaps`	`false`	Configures the caching of Secrets and ConfigMaps by the controller-runtime client. When enabled, it will cache both object types, resulting in increased memory usage and cluster-wide RBAC permissions (list and watch).
`FluxStorage`	`true`	Enables the use of Flux’s own storage implementation for the image tags database.

Flux: Image Reflector API Reference

Mon, 01 Jan 0001 00:00:00 +0000

Flux: Image Update Automation API Reference

Mon, 01 Jan 0001 00:00:00 +0000

Flux: Image Update Automations

Mon, 01 Jan 0001 00:00:00 +0000

The ImageUpdateAutomation API defines an automation process that will update a Git repository, based on ImagePolicy objects in the same namespace.

The updates are governed by marking fields to be updated in each YAML file. For each field marked, the automation process checks the image policy named, and updates the field value if there is a new image selected by the policy. The marker format is shown in the image automation guide.

Example

The following is an example of keeping the images in a Git repository up-to-date:

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
 name: podinfo
 namespace: default
spec:
 interval: 5m0s
 url: https://github.com/fluxcd/example
 ref:
 branch: main
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
 name: podinfo
 namespace: default
spec:
 image: ghcr.io/stefanprodan/podinfo
 interval: 5h
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
 name: podinfo-policy
 namespace: default
spec:
 imageRepositoryRef:
 name: podinfo
 policy:
 semver:
 range: 5.0.x
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: podinfo-update
 namespace: default
spec:
 interval: 30m
 sourceRef:
 kind: GitRepository
 name: podinfo
 git:
 commit:
 author:
 email: fluxcdbot@users.noreply.github.com
 name: fluxcdbot
 messageTemplate: |
 Update container images

 {{ .Changed.Summary }}
 push:
 branch: main
 update:
 path: ./

In the above example:

A GitRepository named podinfo is created, indicated by the GitRepository.metadata.name field. The Git repository at https://github.com/fluxcd/example is assumed to contain YAML files with image policy markers, as described in image automation guide, to update them.
An ImageRepository named podinfo is created, indicated by the ImageRepository.metadata.name field. This scans all the tags for an image repository.
An ImagePolicy named podinfo-policy is created, indicated by the ImagePolicy.metadata.name field.
An ImageUpdateAutomation named podinfo-update is created, indicated by the ImageUpdateAutomation.metadata.name field.
The ImagePolicy refers to the podinfo ImageRepository to query for all the tags related to an image, indicated by ImagePolicy.spec.imageRepositoryRef. These tags are then evaluated to select the latest image with tag based on the policy rules, indicated by ImagePolicy.spec.policy.
The ImageUpdateAutomation refers to podinfo GitRepository as the source that should be kept up-to-date, indicated by ImageUpdateAutomation.spec.sourceRef.
The image-automation-controller lists all the ImagePolicies in the ImageUpdateAutomation’s namespace. It then checks out the Git repository main branch, as configured in GitRepository.spec.ref.branch. It then goes through the YAML manifests from the root of the Git repository, as configured in ImageUpdateAutomation.spec.update.path and applies updates based on the latest images from the image policies. The source changes are saved as a Git commit with the commit author defined in ImageUpdateAutomation.spec.git.commit.author. The commit message is rendered from ImageUpdateAutomation.spec.git.commit.messageTemplate, where .Changed.Summary lists the image updates, see Message Template. The commit is then pushed to the remote Git repository’s main branch, indicated by ImageUpdateAutomation.spec.git.push.branch.
The push commit hash is reported in the ImageUpdateAutomation.status.lastPushCommit field and the push time is reported in .status.lastPushTime field.

This example can be run by saving the manifest into imageupdateautomation.yaml.

Apply the resource on the cluster:

kubectl apply -f imageupdateautomation.yaml

Run kubectl get imageupdateautomation to see the ImageUpdateAutomation:

NAME LAST RUN
podinfo-update 2024-03-17T22:22:34Z

Run kubectl describe imageupdateautomation podinfo-update to see the Last Push Commit and Conditions in the ImageUpdateAutomation’s Status:

Status:
 Conditions:
 Last Transition Time: 2024-03-17T22:22:33Z
 Message: repository up-to-date
 Observed Generation: 1
 Reason: Succeeded
 Status: True
 Type: Ready
 Last Automation Run Time: 2024-03-17T22:22:34Z
 Last Push Commit: 3ebb95cc56d2db59bc6ffbe0d9dd0ea445edeb77
 Last Push Time: 2024-03-17T22:22:34Z
 Observed Generation: 1
 Observed Policies:
 Podinfo - Policy:
 Name: ghcr.io/stefanprodan/podinfo
 Tag: 5.0.3
 Observed Source Revision: main@sha1:3ebb95cc56d2db59bc6ffbe0d9dd0ea445edeb77
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Succeeded 5s (x2 over 6s) image-automation-controller repository up-to-date
 Normal Succeeded 5s image-automation-controller pushed commit '3ebb95c' to branch 'main'
 Update container images

 ghcr.io/stefanprodan/podinfo:5.0.2 -> ghcr.io/stefanprodan/podinfo:5.0.3

Writing an ImageUpdateAutomation spec

As with all other Kubernetes config, an ImageUpdateAutomation needs apiVersion, kind, and metadata fields. The name of an ImageUpdateAutomation object must be a valid DNS subdomain name.

An ImageUpdateAutomation also needs a .spec section.

Source reference

.spec.sourceRef is a required field to specify a reference to a source object in the same namespace as the ImageUpdateAutomation or in another namespace. The only supported source kind at the moment is GitRepository, which is used by default if the .spec.sourceRef.kind is not specified. The source reference name is a required field, .spec.sourceRef.name. The source reference namespace is optional, .spec.sourceRef.namespace. If not specified, the source is assumed to be in the same namespace as the ImageUpdateAutomation. The GitRepository must contain the authentication configuration required to check out the source, if any.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 sourceRef:
 name: <gitrepository-name>
 namespace: <gitrepository-namespace>

By default, GitRepository in a different namespace can be referenced. This can be disabled by setting the controller flag --no-cross-namespace-refs.

The timeouts used in the Git operations for an ImageUpdateAutomation is derived from the referenced GitRepository source. GitRepository.spec.timeout can be tuned to adjust the Git operation timeout.

The proxy configurations are also derived from the referenced GitRepository source. GitRepository.spec.proxySecretRef can be used to configure proxy use.

GitRepository Provider

GitRepository can be configured to specify an OIDC provider for authentication using GitRepository.spec.provider field. Image automation controller can be configured to authenticate using the provider as described below.

For a complete guide on how to set up authentication for cloud providers, see the integration docs.

For a complete guide to the ServiceAccount annotations used for object identity, including the spiffe credential provider, see the Object Identity docs.

Azure

If the provider is set to azure, make sure the pre-requisites are satisfied. To configure image automation controller to use workload identity,

Create a managed identity to access Azure DevOps. Establish a federated identity credential between the managed identity and the image-automation-controller service account. In the default installation, the image-automation-controller service account is located in the flux-system namespace with name image-automation-controller. Ensure the federated credential uses the correct namespace and name of the image-automation-controller service account. For more details, please refer to this guide.
Add the managed identity to the Azure DevOps organization as a user. Ensure that the managed identity has the necessary permissions to access the Azure DevOps repository as described here.
Add the following patch to your bootstrap repository in flux-system/kustomization.yaml file.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
 - gotk-components.yaml
 - gotk-sync.yaml
patches:
 - patch: |-
 apiVersion: v1
 kind: ServiceAccount
 metadata:
 name: image-automation-controller
 namespace: flux-system
 annotations:
 azure.workload.identity/client-id: <AZURE_CLIENT_ID>
 labels:
 azure.workload.identity/use: "true"
 - patch: |-
 apiVersion: apps/v1
 kind: Deployment
 metadata:
 name: image-automation-controller
 namespace: flux-system
 labels:
 azure.workload.identity/use: "true"
 spec:
 template:
 metadata:
 labels:
 azure.workload.identity/use: "true"

GitHub

If the provider is set to github, make sure the GitHub App is registered and installed with the necessary permissions and the github app secret is configured as described here.

Git specification

.spec.git is a required field to specify Git configurations related to source checkout, commit and push operations.

Checkout

.spec.git.checkout is an optional field to specify the Git reference to check out. The .spec.git.checkout.ref field is the same as the GitRepository.spec.ref field. It can be used to override the checkout configuration in the referenced GitRepository. Not specifying this reference defaults to the checkout reference of the associated GitRepository.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 checkout:
 ref:
 branch: <branch-name>

If .spec.git.push is unspecified, .spec.git.checkout will be used as the push branch for any updates.

By default the controller will only do shallow clones, but this can be disabled by starting the controller with flag --feature-gates=GitShallowClone=false.

Commit

.spec.git.commit is a required field to specify the details about the commit made by the automation.

Author

.spec.git.commit.author is a required field to specify the commit author. The author .email is required. The author .name is optional. The name and email are used as the author of the commits made by the automation.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 author:
 email: <author-email>
 name: <author-name>

Signing Key

.spec.git.commit.signingKey is an optional field to specify a signing key to sign the commits with. The signing-key Secret must live in the same namespace as the ImageUpdateAutomation.

The .spec.git.commit.signingKey.type field selects the signing-key format: gpg (default) for OpenPGP keys, or ssh for SSH keys.

OpenPGP

With type: gpg (the default), .secretRef.name refers to a Secret containing an ASCII-armored OpenPGP key in a field named git.asc. If the private key is protected by a passphrase, the passphrase can be specified in the same Secret in a field named passphrase.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 signingKey:
 secretRef:
 name: signing-key
...
---
apiVersion: v1
kind: Secret
metadata:
 name: signing-key
stringData:
 git.asc: |
 <ARMOR ENCODED OPENPGP KEY>
 passphrase: <private-key-passphrase>

SSH

With type: ssh, .secretRef.name refers to a Secret containing the SSH private key in a field named identity, optionally with the key’s passphrase in a field named password. These conventions match the SSH transport-auth Secret format used by GitRepository, so when the ImageUpdateAutomation and the GitRepository share a namespace, a single Secret can serve both transport and signing.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 signingKey:
 type: ssh
 secretRef:
 name: signing-key
...
---
apiVersion: v1
kind: Secret
metadata:
 name: signing-key
stringData:
 identity: |
 <OPENSSH PRIVATE KEY>
 password: <private-key-passphrase>

Supported SSH key algorithms: ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, and ssh-rsa (key size ≥ 2048-bit). Only OpenSSH-format private keys (-----BEGIN OPENSSH PRIVATE KEY-----) are accepted; convert PKCS#1 or PKCS#8 keys with ssh-keygen -p before placing them in the Secret.

Message Template

.spec.git.commit.messageTemplate is an optional field to specify the commit message template. If unspecified, a default commit message is used.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 messageTemplate: |
 Update container images

 {{ .Changed.Summary }}

For a :tag setter that updates 6.5.0 to 6.5.1, the commit message is:

Update container images
ghcr.io/stefanprodan/podinfo tag 6.5.0 -> 6.5.1

.Changed.Summary describes the changes made by the automation in a form ready for the commit message, one line per change. The controller runs an update as soon as an ImagePolicy reports a new image, so the summary usually describes a single image update. Place the summary in the commit body, after a subject line and a blank line, as in the example above.

The form of each line depends on the setter that made the change (see Marking images for update):

Setter	Line
`<namespace>:<policy>`	`<old> -> <new>`
`<namespace>:<policy>:tag`	`<image> tag <old> -> <new>`
`<namespace>:<policy>:digest`	`<image>:<tag> digest <old> -> <new>`
`<namespace>:<policy>:name`	`<image> name <old> -> <new>`

<image> and <tag> are the name and the tag of the latest image reported by the ImagePolicy at the time of the update. The digest line carries the policy’s tag, not the tag in the file, because the new digest is the digest of that tag. Old and new values are printed exactly as they appear in the file, and digests are not shortened.

When an update makes several changes, the lines are sorted and identical lines are merged, so a change made in several files, for example in multiple overlays, is listed once. An image marked with both a tag and a digest setter gets a tag line and a digest line when both values change.

For example, with an ImagePolicy that selects the latest tag and has .spec.digestReflectionPolicy set to Always, and the following kustomization.yaml:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
images:
 - name: podinfo
 newName: ghcr.io/stefanprodan/podinfo # {"$imagepolicy": "flux-system:podinfo:name"}
 newTag: latest # {"$imagepolicy": "flux-system:podinfo:tag"}
 digest: sha256:6129bb944cada32b4662eafd13fd9904d34c77286bf2ec4523eaedb711757cb0 # {"$imagepolicy": "flux-system:podinfo:digest"}

a new image pushed with the latest tag only changes the digest, and the summary is:

ghcr.io/stefanprodan/podinfo:latest digest sha256:6129bb944cada32b4662eafd13fd9904d34c77286bf2ec4523eaedb711757cb0 -> sha256:5f8c3b1e7a0d9b2c4e6f8a1b3c5d7e9f0a2b4c6d8e0f1a3b5c7d9e1f3a5b7c9d

To write the summary as a list, prefix each line in the template:

spec:
 git:
 commit:
 messageTemplate: |
 Update container images

 {{ with .Changed.Summary }}{{ . | replace "\n" "\n- " | printf "- %s" }}{{ end }}

The message template has access to the data related to the changes made by the automation. The template is a Go text template. The data available to the template have the following structure (not reproduced verbatim):

// TemplateData is the type of the value given to the commit message
// template.
type TemplateData struct {
 AutomationObject struct {
 Name, Namespace string
 }
 Changed update.Result
 Values map[string]string
}

// Result contains the file changes made during the update. It contains
// details about the exact changes made to the files and the objects in them. It
// has a nested structure file->objects->changes.
type Result struct {
 FileChanges map[string]ObjectChanges
}

// ObjectChanges contains all the changes made to objects.
type ObjectChanges map[ObjectIdentifier][]Change

// ObjectIdentifier holds the identifying data for a particular
// object. This won't always have a name (e.g., a kustomization.yaml).
type ObjectIdentifier struct {
 Name, Namespace, APIVersion, Kind string
}

// Change contains the setter that resulted in a Change, the old and the new
// value after the Change.
type Change struct {
 OldValue string
 NewValue string
 Setter string
}

The Changed template data field also has helper methods:

// Changes returns all the changes that were made in at least one update.
func (r Result) Changes() []Change

// Objects returns ObjectChanges, regardless of which file they appear in.
func (r Result) Objects() ObjectChanges

// Summary returns a description of the changes, one line per distinct change.
func (r Result) Summary() string

For other formats, range over the fields and methods above, for example:

spec:
 git:
 commit:
 messageTemplate: |
 Automated image update

 Automation name: {{ .AutomationObject }}

 Files:
 {{ range $filename, $_ := .Changed.FileChanges -}}
 - {{ $filename }}
 {{ end -}}

 Objects:
 {{ range $resource, $changes := .Changed.Objects -}}
 - {{ $resource.Kind }} {{ $resource.Name }}
 Changes:
 {{- range $_, $change := $changes }}
 - {{ $change.OldValue }} -> {{ $change.NewValue }}
 {{ end -}}
 {{ end -}}

With template functions, it is possible to manipulate and transform the supplied data in order to generate more complex commit messages.

spec:
 git:
 commit:
 messageTemplate: |
 Automated image update

 Automation name: {{ .AutomationObject }}

 Files:
 {{ range $filename, $_ := .Changed.FileChanges -}}
 - {{ $filename }}
 {{ end -}}

 Objects:
 {{ range $resource, $changes := .Changed.Objects -}}
 - {{ $resource.Kind | lower }} {{ $resource.Name | lower }}
 Changes:
 {{- range $_, $change := $changes }}
 {{ if contains "5.0.3" $change.NewValue -}}
 - {{ $change.OldValue }} -> {{ $change.NewValue }}
 {{ else -}}
 [skip ci] wrong image
 {{ end -}}
 {{ end -}}
 {{ end -}}

There are over 70 available functions. Some of them are defined by the Go template language itself. Most of the others are part of the Sprig template library.

Additional data can be provided with .spec.git.commit.messageTemplateValues.

This is a key/value mapping with string values.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 git:
 commit:
 messageTemplate: |-
 Automated image update by Flux for cluster {{ .Values.cluster }}.
 messageTemplateValues:
 cluster: prod

Push

.spec.git.push is an optional field that specifies how the commits are pushed to the remote source repository.

Branch

.spec.git.push.branch field specifies the remote branch to push to. If unspecified, the commits are pushed to the branch specified in .spec.git.checkout.branch. If .spec.git.checkout is also unspecified, it will fall back to the branch specified in the associated GitRepository’s .spec.sourceRef. If none of these yield a push branch name, the automation will fail.

The push branch will be created locally if it does not already exist, starting from the checkout branch. If the push branch already exists, it will be overwritten with the cloned version plus the changes made by the controller. Alternatively, force push can be disabled by starting the controller with flag --feature-gates=GitForcePushBranch=false, in which case the updates will be calculated on top of any commits already on the push branch. Note that without force push in push branches, if the target branch is stale, the controller may not be able to conclude the operation and will consistently fail until the branch is either deleted or refreshed.

In the following snippet, updates will be pushed as commits to the branch auto, and when that branch does not exist at the origin, it will be created locally starting from the branch main, and pushed:

spec:
 git:
 checkout:
 ref:
 branch: main
 push:
 branch: auto

Refspec

.spec.git.push.refspec field specifies the refspec to push to any arbitrary destination reference. An example of a valid refspec is refs/heads/branch:refs/heads/branch.

Deletion refspecs with an empty source (for example, :refs/heads/branch) and force-update refspecs prefixed with + are not supported. Force pushing is controlled by the GitForcePushBranch feature gate.

If both .push.refspec and .push.branch are specified, then the reconciler will push to both the destinations. This is particularly useful for working with Gerrit servers. For more information about this, please refer to the Gerrit section. This can also be used to automatically open Pull-Requests in Gitea or Forgejo. See the Gitea section for an example.

If only .push.refspec is set, without explicitly defining a .push.branch, the controller falls back to pushing to the branch from checkoutRef and also pushes to .push.refspec.

Note: If both .push.refspec and .push.branch are essentially equal to each other (for e.g.: .push.refspec: refs/heads/main:refs/heads/main and .push.branch: main), then the reconciler might fail with an already up-to-date error.

In the following snippet, updates and commits will be made on the main branch locally. The commits will be then pushed using the refs/heads/main:refs/heads/auto refspec:

spec:
 git:
 checkout:
 ref:
 branch: main
 push:
 refspec: refs/heads/main:refs/heads/auto

Push options

To specify the push options to be sent to the upstream Git server, use .push.options. These options can be used to perform operations as a result of the push. For example, using the below push options will open a GitLab Merge Request to the release branch automatically with the commit the controller pushed to the dev branch:

spec:
 git:
 push:
 branch: dev
 options:
 merge_request.create: ""
 merge_request.target: release

Push retries

When several automations or other writers push to the same branch, a push can be rejected because the branch moved on the remote after the controller cloned it. By default, the push is only attempted again at the next reconciliation.

When the controller is started with the flag --feature-gates=GitPushRetryOnFailure=true, it retries a failed push to the push branch. Before each retry, it waits, discards its commit, catches up with the remote push branch, and applies the policies and commits the changes again. If the remote already has the changes, nothing is pushed. If the remote push branch is at the commit of the failed push, for example because the push timed out after the remote accepted it, the push counts as successful, and the commit is pushed to .spec.git.push.refspec, if set. The wait starts at 2 seconds and doubles for each retry, plus a random jitter of up to 50%. The controller makes up to 5 attempts, and stops retrying at half of .spec.interval or 2 minutes, whichever is shorter, after the first attempt failed, cancelling any clone or push in progress. Failed pushes to .spec.git.push.refspec are not retried, and neither are pushes over HTTP(S) that fail because the credentials are rejected, lack write access, or the repository is not found.

If another writer pushes on top of the commit of a failed push that reached the remote before the controller catches up, the controller finds that the remote already has the changes. As it can’t tell that its own push reached the remote, it does not record the push in the status, does not emit an event, and does not push the commit to .spec.git.push.refspec.

To catch up with the remote, the controller clones the repository again, with the same shallow clone and sparse checkout settings. When the push branch differs from the checkout branch, the GitAllBranchReferences feature gate is enabled, and .spec.git.push.refspec is not set, it clones only the push branch, and clones the checkout branch instead if that fails, for example because the push branch does not exist on the remote. When the feature gate is disabled, the push branch is created from the checkout branch again, as at every reconciliation.

Interval

.spec.interval is a required field that specifies the interval at which the Image update is attempted.

After successfully reconciling the object, the image-automation-controller requeues it for inspection after the specified interval. The value must be in a Go recognized duration string format, e.g. 10m0s to reconcile the object every 10 minutes.

If the .metadata.generation of a resource changes (due to e.g. a change to the spec), this is handled instantly outside the interval window.

ImagePolicy changes also trigger a run outside the interval window (see Policy change delay).

Policy change delay

.spec.policyChangeDelay is an optional field that delays the run triggered by an ImagePolicy reporting a new latest image, so that image updates arriving close together go into one commit. When not set, or set to 0s, the automation runs as soon as a policy changes.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 interval: 30m
 policyChangeDelay: 2m

The delay starts at the first policy change and is not extended by later changes.

The batching is best-effort. Runs triggered by the interval, spec changes, GitRepository changes and manual reconciliation requests are not delayed, and they replace the pending run. Pending runs are not persisted: after a controller restart, every automation runs right away.

This field respects .spec.policySelector. If both are set, only changes to the selected policies trigger a run.

Update

.spec.update is an optional field that specifies how to carry out the updates on a source. The only supported update strategy at the moment is Setters, which is used by default for .spec.update.strategy field. The .spec.update.path is an optional field to specify the directory containing the manifests to be updated. If not specified, it defaults to the root of the source repository.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 update:
 path: </path/to/manifest>

Suspend

.spec.suspend is an optional field to suspend the reconciliation of an ImageUpdateAutomation. When set to true, the controller will stop reconciling the ImageUpdateAutomation, and changes to the resource or image policies or Git repository will not result in any update. When the field is set to false or removed, it will resume.

PolicySelector

.spec.policySelector is an optional field to limit policies that an ImageUpdateAutomation takes into account. It supports the same selectors as Deployment.spec.selector (matchLabels and matchExpressions fields). If not specified, it defaults to matchLabels: {} which means all policies in namespace. When .spec.policyChangeDelay is set, the selector also filters which ImagePolicy changes trigger a run.

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 policySelector:
 matchLabels:
 app.kubernetes.io/instance: my-app
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 policySelector:
 matchExpressions:
 - key: app.kubernetes.io/component
 operator: In
 values:
 - my-component
 - my-other-component

Working with ImageUpdateAutomation

Marking images for update

In order to tell ImageUpdateAutomation to update images in a manifest, the images must be marked with setters. A setter is a comment at the end of a line telling exactly which ImagePolicy to use for that line, and optionally also which field of the image elected as latest by the policy to update in that line. This is useful for example in Helm charts, where images are often defined by multiple values, such as the repository URL, a tag, and optionally a digest.

For example, if you want to use the ImagePolicy my-policy from the flux-system namespace, you could use it in a Deployment like this:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: my-app
 namespace: default
spec:
 template:
 spec:
 containers:
 - name: my-app
 image: ghcr.io/my-org/my-app:4.0.6 # {"$imagepolicy": "flux-system:my-policy"}

Deployments expect the image to be fully specified, including tag and optionally digest, so for Deployments the setter is the basic one, not specifying any fields of the image.

If your app is instead deployed by a Flux HelmRelease whose chart supports image fields, you can use the image fields like this:

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
 name: my-app
 namespace: default
spec:
 values:
 image:
 repository: ghcr.io/my-org/my-app # {"$imagepolicy": "flux-system:my-policy:name"}
 tag: 4.0.6 # {"$imagepolicy": "flux-system:my-policy:tag"}
 digest: sha256:6129bb944cada32b4662eafd13fd9904d34c77286bf2ec4523eaedb711757cb0 # {"$imagepolicy": "flux-system:my-policy:digest"}

Note: For the digest field to be available in the ImagePolicy status, the .spec.digestReflectionPolicy field of the ImagePolicy must be set to IfNotPresent or Always. For a complete guide on digest reflection, see these docs.

Triggering a reconciliation

To manually tell the image-automation-controller to reconcile an ImageUpdateAutomation outside of the specified interval window, an ImageUpdateAutomation can be annotated with reconcile.fluxcd.io/requestedAt: <arbitrary value>. Annotating the resource queues the ImageUpdateAutomation for reconciliation if the <arbitrary-value> differs from the last value the controller acted on, as reported in .status.lastHandledReconcileAt.

Using kubectl:

kubectl annotate --field-manager=flux-client-side-apply --overwrite imageupdateautomation/<automation-name> reconcile.fluxcd.io/requestedAt="$(date +%s)"

Using flux:

flux reconcile image update <automation-name>

Waiting for `Ready`

When a change is applied, it is possible to wait for the ImageUpdateAutomation to reach a ready state using kubectl:

kubectl wait imageupdateautomation/<automation-name> --for=condition=ready --timeout=1m

Suspending and resuming

When you find yourself in a situation where you temporarily want to pause the reconciliation of a ImageUpdateAutomation, you can suspend it using the .spec.suspend field.

Suspend an ImageUpdateAutomation

In your YAML declaration:

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 suspend: true

Using kubectl:

kubectl patch imageupdateautomation <automation-name> --field-manager=flux-client-side-apply -p '{\"spec\": {\"suspend\" : true }}'

Using flux:

flux suspend image update <automation-name>

Resume an ImageUpdateAutomation

In your YAML declaration, comment out (or remove) the .spec.suspend field:

---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: <automation-name>
spec:
 # suspend: true

Note: Setting the field value to false has the same effect as removing it, but does not allow for “hot patching” using e.g. kubectl while practicing GitOps; as the manually applied patch would be overwritten by the declared state in Git.

Using kubectl:

kubectl patch imageupdateautomation <automation-name> --field-manager=flux-client-side-apply -p '{\"spec\" : {\"suspend\" : false }}'

Using flux:

flux resume image update <automation-name>

Debugging an ImageUpdateAutomation

There are several ways to gather information about an ImageUpdateAutomation for debugging purposes.

Describe the ImageUpdateAutomation

Describing an ImageUpdateAutomation using kubectl describe imageupdateautomation <automation-name> displays the latest recorded information for the resource in the Status and Events sections:

...
Status:
 Conditions:
 Last Transition Time: 2024-03-18T20:00:56Z
 Message: processing object: new generation 6 -> 7
 Observed Generation: 7
 Reason: ProgressingWithRetry
 Status: True
 Type: Reconciling
 Last Transition Time: 2024-03-18T20:00:54Z
 Message: failed to checkout source: unable to clone 'https://github.com/fluxcd/example': couldn't find remote ref "refs/heads/non-existing-branch"
 Observed Generation: 7
 Reason: GitOperationFailed
 Status: False
 Type: Ready
 Last Automation Run Time: 2024-03-18T20:00:56Z
 Last Handled Reconcile At: 1710791381
 Last Push Commit: 8084f1bb180ac259c6698cd027064b7dce86a72a
 Last Push Time: 2024-03-18T18:53:04Z
 Observed Generation: 6
 Observed Policies:
 Podinfo - Policy:
 Name: ghcr.io/stefanprodan/podinfo
 Tag: 4.0.6
 Observed Source Revision: main@sha1:8084f1bb180ac259c6698cd027064b7dce86a72a
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Succeeded 11m (x11 over 170m) image-automation-controller no change since last reconciliation
 Warning GitOperationFailed 2s (x3 over 4s) image-automation-controller failed to checkout source: unable to clone 'https://github.com/fluxcd/example': couldn't find remote ref "refs/heads/non-existing-branch"

Trace emitted Events

To view events for specific ImageUpdateAutomation(s), kubectl events can be used in combination with --for to list the Events for specific objects. For example, running

kubectl events --for ImageUpdateAutomation/<automation-name>

lists

LAST SEEN TYPE REASON OBJECT MESSAGE
3m29s (x7 over 4m17s) Warning GitOperationFailed ImageUpdateAutomation/<automation-name> failed to checkout source: unable to clone 'https://github.com/fluxcd/example': couldn't find remote ref "refs/heads/non-existing-branch"
3m14s (x4 over 3h24m) Normal Succeeded ImageUpdateAutomation/<automation-name> repository up-to-date
2m41s (x12 over 174m) Normal Succeeded ImageUpdateAutomation/<automation-name> no change since last reconciliation

Besides being reported in Events, the reconciliation errors are also logged by the controller. The Flux CLI offer commands for filtering the logs for a specific ImageUpdateAutomation, e.g. flux logs --level=error --kind=ImageUpdateAutomation --name=<automation-name>.

Gerrit

Gerrit operates differently from a standard Git server. Rather than sending individual commits to a branch, all changes are bundled into a single commit. This commit requires a distinct identifier separate from the commit SHA. Additionally, instead of initiating a Pull Request between branches, the commit is pushed using a refspec: HEAD:refs/for/main.

As the image-automation-controller is primarily designed to work with standard Git servers, these special characteristics necessitate a few workarounds. The following is an example configuration that works well with Gerrit:

spec:
 git:
 checkout:
 ref:
 branch: main
 commit:
 author:
 email: flux@localdomain
 name: flux
 messageTemplate: |
 Perform automatic image update

 Automation name: {{ .AutomationObject }}

 {{- $ChangeId := .AutomationObject -}}
 {{- $ChangeId = printf "%s%s" $ChangeId ( .Changed.FileChanges | toString ) -}}
 {{- $ChangeId = printf "%s%s" $ChangeId ( .Changed.Objects | toString ) -}}
 {{- $ChangeId = printf "%s%s" $ChangeId ( .Changed.Changes | toString ) }}
 Change-Id: {{ printf "I%s" ( sha256sum $ChangeId | trunc 40 ) }}
 push:
 branch: auto
 refspec: refs/heads/auto:refs/heads/main

This instructs the image-automation-controller to clone the repository using the main branch but execute its update logic and commit with the provided message template on the auto branch. Commits are then pushed to the auto branch, followed by pushing the HEAD of the auto branch to the HEAD of the remote main branch. The message template ensures the inclusion of a Change-Id at the bottom of the commit message.

The initial branch push aims to prevent multiple Patch Sets. If we exclude .push.branch and only specify .push.refspec: refs/heads/main:refs/heads/main, the desired Change can be created as intended. However, when the controller freshly clones the main branch while a Change is open, it executes its update logic on main, leading to new commits being pushed with the same changes to the existing open Change. Specifying .push.branch circumvents this by instructing the controller to apply the update logic to the auto branch, already containing the desired commit. This approach is also recommended in the Gerrit documentation.

Another thing to note is the syntax of .push.refspec. Instead of it being HEAD:refs/for/main, commonly used by Gerrit users, we specify the full refname refs/heads/auto in the source part of the refpsec.

Note: A known limitation of using the image-automation-controller with Gerrit involves handling multiple concurrent Changes. This is due to the calculation of the Change-Id, relying on factors like file names and image tags. If the controller introduces a new file or modifies a previously updated image tag to a different one, it leads to a distinct Change-Id for the commit. Consequently, this action will trigger the creation of an additional Change, even when an existing Change containing outdated modifications remains open.

Gitea

Gitea and Forgejo each implement the AGit-Workflow. This means, the image-automation-controller is able to open a pull-request by pushing to a refspec like HEAD:refs/for/main with the apropriate push-options.

The following example opens a PR on a Gitea or Forgejo-Server:

apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
 name: my-automation
 namespace: flux-system
spec:
 git:
 checkout:
 ref:
 branch: main
 push:
 branch: flux-updates
 refspec: refs/heads/flux-updates:refs/for/main
 options:
 topic: flux-updates
 title: Flux Image Update
 description: |-
 This PR is automatically opened by the fluxcd *image-automation-controller*
 commit:
 author:
 email: flux@eaample.com
 name: fluxcd
 messageTemplate: '{{range .Changed.Changes}}{{print .OldValue}} -> {{println
 .NewValue}}{{end}}'

ImageUpdateAutomation Status

Observed Policies

The ImageUpdateAutomation reports the observed image policies that were considered during the image update in the .status.observedPolicies field. It is a map of the policy name and its latest image name and tag.

Example:

status:
 ...
 observedPolicies:
 podinfo-policy:
 name: ghcr.io/stefanprodan/podinfo
 tag: 4.0.6
 myapp1:
 name: ghcr.io/fluxcd/myapp1
 tag: 4.0.0
 myapp2:
 name: ghcr.io/fluxcd/myapp2
 tag: 2.0.0
 ...

The observed policies keep track of the policies considered in the last reconciliation and is used to determine if the reconciliation can skip full execution due to no change in image policies or remote source.

Observed Source Revision

The ImageUpdateAutomation reports the observed source revision that was checked out during the image update in the .status.observedSourceRevision field. For a GitRepository, the observed source revision would contain the branch name and the commit hash; e.g., main@sha1:8084f1bb180ac259c6698cd027064b7dce86a72a. If the checkout and push branchs are the same, the commit hash of the observed source revision is equal to the last push commit.

The observed source revision keeps track of the source revision seen in the last reconciliation and is used to determine if the reconciliation can skip full execution due to no change in image policies or remote source.

Last Automation Run Time

The ImageUpdateAutomation reports the last automation run time in the .status.lastAutomationRunTime field. It is a timestamp of when the reconciliation ran the last time, regardless of any effective resulting update.

Last Push Commit

The ImageUpdateAutomation reports the last pushed commit for image update in the .status.lastPushCommit field. It is the commit hash of the last pushed commit. The commit has may not be the same that’s present in the observed source revision if the puch branch is different from the checkout branch or the remote repository has new commits which didn’t result in an image update.

Last Push Time

The ImageUpdateAutomation reports the last pushed commit time for image update in the .status.lastPushTime field. It is a timestamp of when the last image update resulted in a pushing of new commit to the source.

Conditions

An ImageUpdateAutomation enters various states during its lifecycle, reflected as Kubernetes Conditions. It can be reconciling while checking out and updating images in source, it can be ready, or it can fail during reconciliation.

The ImageUpdateAutomation API is compatible with the kstatus specification, and reports Reconciling and Stalled conditions where applicable to provide better (timeout) support to solutions polling the ImageUpdateAutomation to become Ready.

Reconciling ImageUpdateAutomation

The image-automation-controller marks an ImageUpdateAutomation as reconciling when one of the following is true:

The generation of the ImageUpdateAutomation is newer than the Observed Generation.
The ImageUpdateAutomation has observed new ImagePolicies or changes in the ImagePolicies’ latest images, or change in the remote source.

When the ImageUpdateAutomation is “reconciling”, the Ready Condition status becomes Unknown, and the controller adds a Condition with the following attributes to the ImageUpdateAutomation’s .status.conditions:

type: Reconciling
status: "True"
reason: Progressing

It has a “negative polarity”, and is only present on the ImageUpdateAutomation while its status value is "True".

Ready ImageUpdateAutomation

The image-automation-controller marks an ImageUpdateAutomation as ready when it has the following characteristics:

The controller was able to check out the remote source repository using the specified GitRepository configurations.
The ImageUpdateAutomation could not find any update to the source, already up-to-date.
The ImageUpdateAutomation pushes image updates to the source, making it up-to-date.

When the ImageUpdateAutomation is “ready”, the controller sets a Condition with the following attributes in the ImageUpdateAutomation’s .status.conditions:

type: Ready
status: "True"
reason: Succeeded

This Ready Condition will retain a status value of "True" until a failure occurs due to any reason.

Failed ImageUpdateAutomation

The image-automation-controller may get stuck trying to update a source without completing. This can occur due to some of the following factors:

The remote source is temporarily unavailable.
The referenced source is in a different namespace and cross-namespace reference is disabled.
The referenced source does not exist.
The credentials associated with the source are invalid.
The source configuration is invalid for the current state of the source, for example, the specified branch does not exists in the remote source repository.
The remote source repository prevents push or creation of new push branch.
The policy selector is invalid, for example, label is too long.

When this happens, the controller sets the Ready Condition status to False with the following reasons:

reason: AccessDenied | reason: InvalidSourceConfiguration | reason: GitOperationFailed | reason: UpdateFailed | reason: InvalidPolicySelector

While the ImageUpdateAutomation is in failing state, the controller will continue to attempt to update the source with an exponential backoff, until it succeeds and the ImageUpdateAutomation is marked as ready.

Note that an ImageUpdateAutomation can be reconciling while failing at the same time, for example due to a newly introduced configuration issue in the ImageUpdateAutomation spec.

Observed Generation

The image-automation-controller reports an observed generation in the ImageUpdateAutomation’s .status.observedGeneration. The observed generation is the latest .metadata.generation which resulted in either a ready state, or stalled due to error it can not recover from without human intervention.

Last Handled Reconcile At

The image-automation-controller reports the last reconcile.fluxcd.io/requestedAt annotation value it acted on in the .status.lastHandledReconcileAt field.

For practical information about this field, see triggering a reconcile.

Flux – Image reflector and automation controllers

Flux: Controller Options

Image automation flags

SPIFFE mTLS

SPIFFE Broker API

Feature Gates

Image reflector flags

SPIFFE mTLS

SPIFFE Broker API

Feature Gates

Flux: Image Reflector API Reference

Flux: Image Update Automation API Reference

Flux: Image Update Automations

Example

Writing an ImageUpdateAutomation spec

Source reference

GitRepository Provider

Azure

GitHub

Git specification

Checkout

Commit

Author

Signing Key

OpenPGP

SSH

Message Template

Push

Branch

Refspec

Push options

Push retries

Interval

Policy change delay

Update

Suspend

PolicySelector

Working with ImageUpdateAutomation

Marking images for update

Triggering a reconciliation

Waiting for Ready

Suspending and resuming

Suspend an ImageUpdateAutomation

Resume an ImageUpdateAutomation

Debugging an ImageUpdateAutomation

Describe the ImageUpdateAutomation

Trace emitted Events

Gerrit

Gitea

ImageUpdateAutomation Status

Observed Policies

Observed Source Revision

Last Automation Run Time

Last Push Commit

Last Push Time

Conditions

Reconciling ImageUpdateAutomation

Ready ImageUpdateAutomation

Failed ImageUpdateAutomation

Observed Generation

Last Handled Reconcile At

Waiting for `Ready`