Skip to content
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

Automate updating patch releases calendar on the Kubernetes website #3179

Open
xmudrii opened this issue Jul 27, 2023 · 11 comments · May be fixed by kubernetes/website#45762
Open

Automate updating patch releases calendar on the Kubernetes website #3179

xmudrii opened this issue Jul 27, 2023 · 11 comments · May be fixed by kubernetes/website#45762
Assignees
Labels
area/release-eng Issues or PRs related to the Release Engineering subproject kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/release Categorizes an issue or PR as relevant to SIG Release. triage/accepted Indicates an issue or PR is ready to be actively worked on.

Comments

@xmudrii
Copy link
Member

xmudrii commented Jul 27, 2023

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
@xmudrii xmudrii added kind/feature Categorizes issue or PR as related to a new feature. sig/release Categorizes an issue or PR as relevant to SIG Release. area/release-eng Issues or PRs related to the Release Engineering subproject labels Jul 27, 2023
@xmudrii xmudrii added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Jul 27, 2023
@xmudrii
Copy link
Member Author

xmudrii commented Jul 27, 2023

@kubernetes/release-engineering Some feedback would be appreciated on this issue. This also might be a good issue for Release Manager Associates.

@sftim
Copy link
Contributor

sftim commented Jul 27, 2023

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.

@k8s-triage-robot
Copy link

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/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was 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

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 25, 2024
@xmudrii
Copy link
Member Author

xmudrii commented Jan 25, 2024

/remove-lifecycle stale

@k8s-ci-robot k8s-ci-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 25, 2024
@dweineha
Copy link

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.

@cpanato
Copy link
Member

cpanato commented Feb 20, 2024

the only issue I can see, but that can be manually updated, is the dates, which we sometimes change for some reasons, like Kubecon...

@sftim
Copy link
Contributor

sftim commented Feb 20, 2024

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.

@saschagrunert
Copy link
Member

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

@saschagrunert
Copy link
Member

@kubernetes/release-managers would anyone like to work on this? We forgot to update the website for the March patches.

@sftim
Copy link
Contributor

sftim commented Apr 3, 2024

Given that there's a PR open:
/triage accepted

@k8s-ci-robot k8s-ci-robot added the triage/accepted Indicates an issue or PR is ready to be actively worked on. label Apr 3, 2024
@cpanato
Copy link
Member

cpanato commented Apr 3, 2024

too late to the party :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/release-eng Issues or PRs related to the Release Engineering subproject kind/feature Categorizes issue or PR as related to a new feature. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. sig/release Categorizes an issue or PR as relevant to SIG Release. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants