Hey all! We've just switched our infrastructure to utilize Kubernetes for production and staging environments. We follow trunk-based development and use semantic versioning for our API releases. Now that staging is added, I'm needing to implement `-rc` tags for release candidates. Here's the thing: we currently tag our Docker images with the same version as our app, like 1.1.0. However, if a security update comes in for the OS, I want to update the Docker image without changing the app version. I considered using build metadata, but I've read that doesn't help in indicating a newer image.
For example, if we have 1.1.0+20251020, it won't show up as newer than just 1.1.0 according to ArgoCD's image updater. How do you all handle this type of situation? Do you have to force a new app version every time there's an OS update? It seems inefficient. Should I just switch to a custom tag like 1.0.0-osbuild.20251020 or 1.1.0-rc-osbuild.20251020 and leverage regex in ArgoCD for managing images? I'm curious about the practices other companies adopt for this issue, especially since we have a fully automated CI/CD process. Thanks for any insights!
5 Answers
We have a pretty straightforward approach: any change—whether it's in the Dockerfile or tests—results in a git tag that bumps the app's version. In my experience, any modification should be ready for production right away, but I get that with rapid changes, it can become tricky.
Honestly, you might be overcomplicating things! Automated versioning isn't a hassle and doesn’t have to be intuitive. Whether you decide to add timestamps to your tags or bump the minor version, the main goal is to keep the process smooth.
I suggest focusing on versioning the build artifacts rather than the app itself. Since the container image is your primary artifact, any time it changes (like a different base image), you should increment the version due to the different image hash. This keeps everything tighter and reduces confusion.
In our setup, we treat the Docker image and app versions as closely linked. If we make any changes—be it a security update or new features—it mandates a new version number for the app. We always ensure our versioning reflects any change in the system appropriately.
In our company, we follow a pattern like ---. The candidate types help us classify our releases and streamline the build process. This way, there's little confusion, as each tag provides extensive detail on the version and environment it was built for.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically