Render list of releases using a content adapter

[sftim]

This is a Feature Request

What would you like to be added
Partially Revise https://kubernetes.io/releases/ to have some pages rendered using a content adapter.

For example:

• https://kubernetes.io/releases/v1.30.0/ becomes a new page about the v1.30.0 release
  • …with a link to the announcement blog article.
  • There are download links (and signatures, etc)
  • There's a link to the changelog
  • there's a link to the tag at GitHub
• https://kubernetes.io/releases/v1.30.1/ becomes a new page about the v1.30.1 patch release with some details
  • and a link to https://kubernetes.io/releases/v1.30.0/
  • There are download links etc
  • There's a link to the changelog
  • There's a link to the tag at GitHub
• https://kubernetes.io/releases/v1.29.0/ becomes a new page about the v1.29.0 release
  • …with a link to the announcement blog article
  • There are download links (and signatures, etc)
  • There's a link to the changelog
  • There's a link to the v1.29 documentation
• https://kubernetes.io/releases/v1.19.0/ becomes a new page about the v1.19.0 release
  • …with a link to the announcement blog article
  • There are download links (and signatures, etc)
  • There's a link to the changelog
• https://kubernetes.io/releases/v1.12.3/ becomes a new stub page with details of the v1.12.3 patch release.
  • there's a link to the tag at GitHub
  • and a link to https://kubernetes.io/releases/v1.12.3/
  • but no download links because we don't offer downloads for releases that old

Why is this needed
It provides a better place and “one stop shop” for people who want to find out about our releases, new and old.

Comments
/area web-development
/sig release

We would need to be using Hugo v0.126 or later.

[k8s-ci-robot]

This issue is currently awaiting triage.

SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sftim]

We should only make this change if we think it's a good idea.

[dipesh-rawat]

+1 from me for this. This looks like a nice feature to incorporate.

[PushkarJ]

This is a great idea. I want to try this for kubernetes/sig-security#1 to auto-generate CVE pages.

Can I request SIG Docs to create a container image that supports this new feature in v0.126.0? Getting this error right now:

personal-macbook:website pushkarj$ make container-serve
"docker" run --rm --interactive --tty --volume "/Users/pushkarj/opensource-ftw/kubernetes/website:/src:ro,Z" --cap-drop=ALL --cap-add=AUDIT_WRITE --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 -p 1313:1313 gcr.io/k8s-staging-sig-docs/k8s-website-hugo:v0.126.0-663380dd60a2 hugo server --buildFuture --environment development --bind 0.0.0.0 --destination /tmp/hugo --cleanDestinationDir --noBuildLock
Unable to find image 'gcr.io/k8s-staging-sig-docs/k8s-website-hugo:v0.126.0-663380dd60a2' locally
docker: Error response from daemon: manifest for gcr.io/k8s-staging-sig-docs/k8s-website-hugo:v0.126.0-663380dd60a2 not found: manifest unknown: Failed to fetch "v0.126.0-663380dd60a2" from request "/v2/k8s-staging-sig-docs/k8s-website-hugo/manifests/v0.126.0-663380dd60a2".

[sftim]

I've messaged you @PushkarJ about how to preview the site with a different Hugo version.