Open kd7lxl opened 3 years ago
This sounds nice, they're not currently, and they're pushed and the hashes recorded by hand currently, so this would be somewhat kludgey to produce ourselves.
We'd love to automate that, but there's several other issues related to image publishing we need to look at first #1895 etc. and these are just published as a convenience https://kind.sigs.k8s.io/docs/contributing/project-scope/
This issue seems strongly related to #2349 #2114 in particular.
One small thing that could help here, right now the images published are 1.20.1, 1.21.1, 1.22.1, 1.23.1, ... this means that there is no tag I can use in the Docker registry API to grab the latest available version for the line 1.20, or 1.25. Publish the latest version available of each line will allow to detect a new version and make a PR in our repos with the changes to update to the new version. For example, the current 1.25.3 is the latest version if I publish the 1.25 tag too along with 1.25.3, I can use updatecli to make a PR updating the version and testing if the new Docker image will work before making any change.
You should not just be grabbing tags from the registry, they may not work with the kind version you are using. See the docs, release notes and the linked issues.
We have a similar problem in Kong/kubernetes-ingress-controller. For our use case, it would be good enough just to grab the newest available version for each minor K8s version supported by us. But kindtest/node
images unfortunately do not have tags like 1.27
, 1.26
, etc. I know that specifying the exact version is more robust, but it is tedious to keep them up to date in the tests matrix.
Would you mind starting tagging the newest patch version for each minor with the minor only tag too? E.g. kindest/node:v1.27.3
should have the tag kindest/node:v1.27
too. It's common practice for images e.g. Linux distro's based images, programming languages images, etc. I think (keeping in mind the comment above) it would be just good enough for many use cases
Would you mind starting tagging the newest patch version for each minor with the minor only tag too? E.g. kindest/node:v1.27.3 should have the tag kindest/node:v1.27 too. It's common practice for images e.g. Linux distro's based images, programming languages images, etc. I think (keeping in mind the comment above) it would be just good enough for many use cases
We might, but realistically the focus is on completely revamping the entire image publishing to registry.k8s.io with a different scheme which will require immutable tags because of how kubernetes the project manages things. We have discussion about that in another issue open in the tracker.
We use kind in our CI to test against multiple versions of Kubernetes. We want to verify our code against the three latest minor versions of Kubernetes. We want to be able to automate discovery of the corresponding
kindest/node
images for these releases.The docs suggest the procedure to discover the image tags is to read the release description: https://github.com/kubernetes-sigs/kind/releases/tag/v0.11.1
Are these published in any machine-readable way? It would be great if they were published in something like json.
I've developed a kludge/workaround that scrapes the body of the release notes from the Github API, but this doesn't seem like a reliable long term solution.