Open jpflouret opened 1 year ago
Hi @jpflouret, apart from the latest
tag, containers are built and tagged for ever commit that is built with the commit's SHA: https://github.com/squat/generic-device-plugin/pkgs/container/generic-device-plugin.
I these image tags sufficient until the time we tag a 0.1.0?
Nevertheless, I want to disable pushing the latest tag when CI runs on the schedule because it's incorrect to be overwriting tagged images (other than latest
).
Using commit hashes is not ideal. How is a user supposed to know if a commit is safe to use or was only work in progress? How does a user know it was from main and not from a dev branch? Additionally, given the random nature of commit hashes, how does a user know if an image is newer than another one just by looking at the image tag?
The lack of versioning also means that the manifests use latest
(by omission) so applying the manifest as described in the readme makes a deployment (ok it's a daemonset) that cannot be relied upon to not change randomly.
TL;DR; I think you should start using version tags right now. You could use 0.0.1-alpha or 0.0.1-experimental etc. You don't have to commit to version 1.0.0 or even 0.1.0 but I do think tags are necessary.
There are no versioned releases in the project and there is only the
latest
tag published which changes every night with CI build pushing new builds. This can result in version differences between pod instances in the daemonset when new nodes are added. Perhaps adding tags when new code releases happen and publishing those tags as docker image tags would be a solution.