I am not sure if it is best practice, but this is what I do and it might provide some inspiration:

• Bootstrap from a private gitlab.com repository with a base ansible setup. Executed from a laptop.
• The bootstrap setups up k8s and installs a bare bones git repository docker container based on https://codeberg.org/al13nsc13nc3/gitsrv.
• Flux CD is installed into the bare bones git repository and k8s.
• Flux CD is used to install Forgejo and Woodpecker CI using the bare bones git repository as the gitops source of truth.

This has the advantage that Gitops and normal git repositories are separate. I think that a similar principle would work with docker compose instead of k8s.

The person that found this is a hero.

Whenever I see slightly weird behaviour, there is a temptation to just move on because there isn’t enough time, running software is complicated, and there is something else I want to do. I will try to change my attitude in future in case it uncovers a backdoor like this – it would be educational too.

I looked at Tekton, but the complexity of doing simple things put me off. I have been running woodpecker which now has Kubernetes support.

Installing the Helm Chart for the Woodpecker agent gives K8s support with no special configuration needed. My needs are simple but I have been really impressed with how easy it has been.

For a fun comparison, a reasonable 1TB USB Stick costs slightly less than 1TB of AWS egress.

The manifest of my Kubernetes cluster is managed in a Git repository and is automatically deployed via a GitOps tool named Flux CD. When I push changes to the repository, such as adding a new application or upgrading Docker images, the deployment occurs within a few minutes.

This is the way.

Although I use Flux ImageUpdateAutomation instead of Renovate Bot. Did you consider using Flux to do auto updates? Are there any downsides that made you choose Renovate Bot instead?

I found the most interesting bit was this at the end:

• You can now specify a new RestartPolicy: Always configuration for an init container.
• If you add that new config, you now have a sidecar container.
• A sidecar container starts before all ordinary containers (because it’s an init container), and—this is the big part—it now terminates after all the ordinary containers all terminate.
• If for some reason your sidecar container dies while ordinary containers are running, it will be restarted automatically. (This is the “Always” bit.)
• Finally, unlike with normal init containers that each wait in turn to complete before the next starts, the other init containers do not wait for sidecar containers to complete before starting. Which is good, because they’re not going to complete until much later.