-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: autogenerate tested k8s versions and centralize config #14176
Conversation
The `Kubernetes Compatibility Matrix` table at https://argo-workflows.readthedocs.io/en/latest/releases/ is misleading, since it isn't actually representing what versions are being tested ([Slack conversation](https://cloud-native.slack.com/archives/C0510EUH90V/p1732621744050569)). This makes it so that table is autogenerated for every release branch, while for `latest` it'll show a message telling the user to switch to a version. That's identical to what ArgoCD is currently doing, e.g.: * https://argo-cd.readthedocs.io/en/latest/operator-manual/installation/#tested-versions * https://argo-cd.readthedocs.io/en/release-2.9/operator-manual/installation/#tested-versions See argoproj/argo-cd#14180 for the corresponding PR on Argo CD, which is what I based this on, but I made several simplifications (e.g. instead of using switching to old release branches in `supported-versions.sh`, I had it just use `git grep` to directly extract the relevant version data). I also updated `.devcontainer/pre-build.sh` to use the same `hack/k8s-versions.sh` script for determining the k3d version, which eliminates the need to update that file when upgrading Kubernetes. Signed-off-by: Mason Malone <[email protected]>
/retest |
docs/tested-kubernetes-versions.md
Outdated
@@ -0,0 +1 @@ | |||
This page is populated for released Argo Workflows versions. Use the version selector to view this table for a specific version. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mean that we will only generate the table on releases? If that's the case should we manually add the matrix here until the next release is made?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, this file will be only be replaced with the table when the Docs
workflow is run on release branches. But that doesn't make this message inaccurate, because the release branches will still have old docs containing the Kubernetes Compatibility Matrix
table.
Also, using the cherry-pick bot that @Joibel just added (#14151), it should be easy to cherry-pick this onto release-3.6
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this, but question the table containing "other" versions than the one we're looking at.
I believe this will need manually running when we cherry-pick backwards otherwise docs linting will fail, but that's fine.
hack/docs/supported-versions.sh
Outdated
echo "| Argo Workflows version | Kubernetes versions |" | ||
echo "|------------------------|---------------------|" | ||
|
||
for n in 0 1 2; do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why iterate back like this at all? Why not force the user to look at the page for the version they are using instead?
The table for other release numbers may be wrong as an update to k8s version may have occurred on their branch but a release not happened. If we cherry-pick this back to 3.5 then it will iterate back to 3.3 which is even more unsupported than 3.4, and at some point this breaks with a 4.0 release. And at 3.7 release 3.6 will continue to want to document 3.4.
I'd rather we always displayed the "version selector" sentence, and just showed the current branch.
We do lose the version information for main
/latest
which is probably a healthy thing, so I agree with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a user is on an older Kubernetes version and they want to determine what version(s) of Argo Workflows they can use, then a table provides a better user experience than manually switching between versions. But that's probably not common enough to be worth the extra complexity, so I went ahead and rewrote this to only print a single sentence with the tested Kubernetes versions for the current version. That means hack/k8s-versions.sh
no longer needs to be compatible with old release branches, so I updated it to be a simple config file that defines the minimum and maximum Kubernetes versions, which is cleaner.
Signed-off-by: Mason Malone <[email protected]>
Signed-off-by: Mason Malone <[email protected]>
Signed-off-by: Mason Malone <[email protected]>
/retest |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice, I like this
/cherry-pick release-3.6 |
/cherry-pick release-3.5 |
Cherry-pick failed with |
Cherry-pick failed with |
Motivation
The
Kubernetes Compatibility Matrix
table at https://argo-workflows.readthedocs.io/en/latest/releases/ is misleading, since it isn't actually representing what versions are being tested (Slack conversation).ArgoCD autogenerates the corresponding table for released versions, and includes a message for
latest
telling the user to switch to a release:Modifications
The original version of this PR was based on argoproj/argo-cd#14180, but I subsequently rewrote it to get rid of the table and only show a single sentence with the tested Kubernetes versions.
I also updated
.devcontainer/pre-build.sh
to use the samehack/k8s-versions.sh
script for determining the k3d version, which eliminates the need to update that file when upgrading Kubernetes.Verification
Documentation
Verified this works on release branches by running

git tag v3.6.9
, then runningmake docs-serve
and visiting http://127.0.0.1:8000/en/latest/releases/#tested-versions: