Flux, the GitOps tool, can report its reconciliation status directly back to your Git commits.
Let’s see it in action. Imagine you have a Kubernetes deployment managed by Flux.
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
namespace: default
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: nginx:1.25.0
ports:
- containerPort: 80
When Flux commits this deployment.yaml to your Git repository, it continuously monitors your Kubernetes cluster. If the cluster’s state doesn’t match what’s declared in Git (e.g., nginx:1.25.0 is not running, or only 2 replicas are available instead of 3), Flux will attempt to reconcile this difference.
Once Flux has successfully applied the changes and the cluster state now matches the Git commit, it can update that specific Git commit with a status. This is typically done by adding a "commit status" or "check" to the commit itself.
This mechanism allows you to see at a glance, directly within your Git history, whether the state declared in a particular commit has been successfully applied to your cluster.
Here’s how it works internally. Flux, after reconciling, sends an API call to your Git provider (GitHub, GitLab, Bitbucket, etc.). This API call includes information about the commit SHA, the status (e.g., success, failure, pending), a descriptive name for the check (often flux-reconciliation), and a URL pointing to more details (usually the Flux dashboard or a specific reconciliation event). Your Git provider then displays this status prominently on the commit page, often as a green checkmark, a red X, or a spinning icon.
The primary problem this solves is providing immediate, auditable feedback on the deployment status directly within the developer’s workflow. Instead of needing to log into a CI/CD system or a Kubernetes dashboard to check if a change was applied, developers can see the reconciliation status right next to the code they committed. This closes the loop between code and infrastructure.
You control this behavior through Flux’s configuration. Specifically, you’ll configure the GitRepository or HelmRepository sources to point to your Git repository. The reconciliation status reporting is an output of the Kustomization or HelmRelease resources. You don’t typically "enable" it; it’s a feature that’s available when Flux is configured to manage resources from Git. The exact appearance and behavior depend on your Git provider’s API and how Flux interacts with it.
The one thing most people don’t know is that the status reported back to Git isn’t just a simple "applied" or "not applied." Flux can report granular statuses for different reconciliation phases or even specific resource types if configured to do so, though the default is a general reconciliation success or failure. This means you could, in theory, have a commit show a "pending" status for a database migration and then a "success" status for the application deployment that depends on it, all reported against the same commit.
The next concept you’ll likely encounter is handling reconciliation failures and setting up alerts for them.