Automate updating patch releases calendar on the Kubernetes website
What would you like to be added:
We have a patch releases calendar on the Kubernetes website. However, that patch release calendar is updated manually by updating schedule.yaml file in k/website.
This tends to get forgotten from time to time which causes confusion for the end users. I think that we should consider automating this task as a way to ensure that the calendar is up to date but also to reduce load on Release Managers as this must be done manually each time.
Why is this needed:
- A lot of end users are using that calendar as a reference what's the latest patch release available
@kubernetes/release-engineering Some feedback would be appreciated on this issue. This also might be a good issue for Release Manager Associates.
The website can load in a JSON schedule, if we want to make one.
Another approach: build an alert that notifies when there's a patch release done but isn't done on the website. Along with a script to run that makes the right PR.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
The fact that schedule.yaml is only manually updated, combined with the fact that packages are now released through OBS which has separate paths for every new version, means that there is (to the best of my knowledge) no reliable way to check for new upstream releases, with schedule.yaml sometimes lagging (notably 1.29.1 was listed as the latest version several days).
Having a automatically generated machine-parsable file would be very helpful, not only for the release calendar, but also for checking for automated checks for new releases.
the only issue I can see, but that can be manually updated, is the dates, which we sometimes change for some reasons, like Kubecon...
We can consider opening a PR but leave the approval to a human.
There are APIs to make it possible, for sure. Contributor cycles, I'm not so sure about.
I agree having the PR automatically proposed would be a benefit. The automatic index update job does something similar for downloadkubernetes.com: https://github.com/kubernetes-sigs/downloadkubernetes/actions
https://github.com/kubernetes-sigs/downloadkubernetes/blob/master/cmd/update-index/main.go
@kubernetes/release-managers would anyone like to work on this? We forgot to update the website for the March patches.
Given that there's a PR open: /triage accepted
too late to the party :(