I'm working with a GitOps workflow using FluxCD and I'm facing some issues with CI/CD sync. Here's the scenario: whenever I push changes to my GitLab repository, the Docker build and push process takes about 5 minutes. However, FluxCD checks the repo for updates every minute. If I merge a feature into the main branch during this period, it starts deploying to my production Kubernetes cluster too soon, before the Docker image has finished building. Is there a way to configure FluxCD to prevent this race condition? Should I be manually updating the image hash during the deployment instead?
3 Answers
You might want to check out Flux webhooks. By using these, you can push the new image tag to your Git repo only after the build is complete, which helps avoid premature deployments.
Fundamentally, FluxCD won’t deploy just because it sees a change in the repo. The deployment should only be triggered when there’s a new, ready-to-deploy artifact or image tag. That way, you avoid deploying older images that aren't built yet.
You got it! The way FluxCD triggers deployments is linked to changes in your Git repo, and your CI pipeline should focus on building the Docker image first. Once the image is built and pushed to the registry, the Image Automation Controller can then bump the code in your Git repo, which will trigger the deployment in Kubernetes.
Exactly! If FluxCD triggers deployments based on changes in the registry instead of just the repo, it can help you dodge the mismatch problem.