How do you add a build step to the gitops flow?

[kachar]

We're trying to pick a simplistic way of handling the deployment pipeline and the decisions are not binary.
I really prefer the way this project handles the gitops in comparison with Rancher Continuous Delivery flow with Fleet.

What we want to achieve:

• Rancher dashboard for kubernetes overview
• One frontend app, one backend app, two db instances all stored in private mono-repo
• Pipeline that
  • builds the images and pushes them to a registry
  • runs the tests
  • deploys the images on given cluster (staging/production)

As I see GitOps Toolkit can help me along the way with the automatic deploy to the cluster, but what about the build step?

How does the building of the images fit into the GitOps Toolkit flow?
Do I have to use Rancher Pipeline to build the images and run the tests, and then deploy them via the toolkit?

[kgorskowski]

I am having some problems wrapping my head around a similar problem. I guess the workflow from "git push" to "build, test and push and updated docker image" is pretty straightforward and is done via the pipeline tool of your choice (I usually use gitlab in most projects, this is pretty "gitops" compatible imho). But I am lacking the understanding of how to have the deployment as "far away from the dev" as possible. Flux 1 was able to scan a registry for a new image, update the deployment and push the changes back to git for review/merge. This feature is not yet implemented in fluxv2 so "someone" must check in and commit the new image reference for flux to pick it up? Thats usually not something you would like to do manually. Only alternative I could think of would be to automate the packaging of an update helm chart but thats not practical in all cases. So yeah, I really would like to dig deeper into the gitops workflow but I am also still missing some moving parts I guess

[stefanprodan]

This is how it can be done from CI https://github.com/gitopsrun/webapp-frontend/blob/master/.github/workflows/staging.yaml#L34-L49, after the image gets pushed, you would use kustomize set image and commit the tag change to a deploy branch that gets synced into the cluster.

[kgorskowski]

I will have a look thanks for the nudge in the right direction (although I must admit I not a huge fan of committing/pushing to git from a pipeline step. but thats just me atm). Right now I am trying to establish the flux/gotk workflow for a smaller project in production, so your introductions and examples really help there a lot

[stefanprodan]

This approach has a major advantage over Flux v1 image updates, if a code change requires a config change (some env var or config map or secret), Flux v1 would update the image tag and your app would crash if you don't manually push the config changes at the same time when Flux commits the tag change. Doing it from CI, means that config and tag changes are pushed to the deploy branch at the same time.