Improvement tasks for v1.4 release cycle

[ykakarap]

NOTE: To be clear, this is a list of potential improvements and is meant as a backlog.
The idea is not that we have to implement all of those within the v1.4 release cycle.
It's also an umbrella issue, please create separate issues for the individual sub-tasks.

CI Signal/Bug Triage/Automation Manager/Team

• Automate release branch and tag creation: Automate release branch and tag creation #7128
• Security Self-Assessment: [STRIDE-TAMPER-1] Produce a SBoM #6153 (depends on upstream implementation) (@furkatgofurov7)
• cc release team on image promotion PRs: 🌱 cc @cluster-api-release-team when auto-opening the PR to promote images from staging to prod #7487
• cc release team on cherry-pick PRs (@nawazkh)
  • Best way to do it, is probably by extending the cherrypicker in test-infra
  • Alternative or temporary solution could be a GitHub action in the cluster-api repo
• Theoretically we can use k8s-triage to generate bug reports for flaky tests via "file bug" (link). Unfortunately the issues are always filed against k/k so we have to manually copy&paste the issue text to a Cluster API repo. Let's see if we can improve k8s-triage to be able to create issues in the Cluster API repo. (@aniruddha2000)
• Consider implementing a tool to generate our ProwJob YAMLs to make the jobs easier to manage (@sbueringer)
  • also check if there is already something like that
• Improve the Homebrew publish process (@alexander-demicev)
  • Context: Homebrew publish on release does not work #6613
• Improve the Netlify access model. Right now only limit people have access to the Netlify and for doing any thing regarding Netlify the people with access have to do some manual work. There is scope to improve this, either through more automation or more shared access.

Communications/Docs/Release Notes Manager/Team

• Define details of "Communicate key dates to the community"
• Consider adding expandable auto-generated release notes for beta and RC (non-GA) releases
• Ensure we have documentation on how to consume beta / RC releases (for users)
• Potential improvements to generating release notes that automatically have the clusterctl: or E2E: or KCP: against the PR titles. Currently this process is done manually. May be we can improve this my looking at the area/xxx label of the PR or even consider some kind of PR title validation to make sure that users provide the prefix (kind of like how they currently provide ✨ , 🌱 , etc)
• Document how to consume nightly Cluster API releases with clusterctl and with the test framework

Misc

• Having a team alias in the OWNER/OWNER_ALIASES file so that it could be potentially used as a single source of truth where we need to know the list of release team members - could be used in some kind of automation.
  • Example: To tag members of the release team on PR (may be auto generated) on repos outside of the kuberetens-sigs org, like kubernetes/test-infra repo.
  • Context: 🌱 cc @cluster-api-release-team when auto-opening the PR to promote images from staging to prod #7487 (comment)

[sbueringer]

/triage accepted

[sbueringer]

/assign @ykakarap
(for tracking during the v1.4 release cycle)

[ykakarap]

cc @kubernetes-sigs/cluster-api-release-team

[aniruddha2000]

Hi @kubernetes-sigs/cluster-api-release-team 👋🏻 I am planning to work on this issue

Theoretically we can use k8s-triage to generate bug reports for flaky tests via "file bug" (link). Unfortunately, the issues are always filed against k/k so we have to manually copy&paste the issue text to a Cluster API repo. Let's see if we can improve k8s-triage to be able to create issues in the Cluster API repo.

Can anyone help me with where I can find the current k8s-triage related work?

[fabriziopandini]

FYI, I saw that trivy (the tool that we are starting to use for CVE scanning) can be used to generate SBOM

[sbueringer]

Can anyone help me with where I can find the current k8s-triage related work?

The only thing I know about it is essentially its URL. I would recommend asking in #sig-testing in the Kubernetes Slack.

FYI, I saw that trivy (the tool that we are starting to use for CVE scanning) can be used to generate SBOM

Afaik Kubernetes already generates SBOM's, I think it would be good to check if we can re-use their tooling.

[sbueringer]

General suggestion: when folks are starting to work on specific sub-tasks, let's please create/generate a separate issue from the sub-task so we can address/assign/close them individually.

[ykakarap]

@furkatgofurov7
I see that you are assigned to the item: "Produce SBOM for releases (@furkatgofurov7)". Is this the same as the Security Self-Assessment item "#6153 (depends on upstream implementation)" item in the list? Is this different?

[furkatgofurov7]

@furkatgofurov7
I see that you are assigned to the item: "Produce SBOM for releases (@furkatgofurov7)". Is this the same as the Security Self-Assessment item "#6153 (depends on upstream implementation)" item in the list? Is this different?

@ykakarap yeap, I think we were not able to find 6153 (during the meeting) when we were going through them, so we created a new one, in short it is a duplicate of 6153

[ykakarap]

Thank you. I am dropping the duplicate.

[joekr]

From the Comms team we have created issue #8263 to try to make note generation easier to automate and the associated PR #8260 to update our PR template to ask users to self label.

[ykakarap]

@joekr Looks like you moved all pending items from this issue into the 1.5 improvements issue. Can I close this?

[joekr]

yukirii yeah I'll track in the 1.5 issue until we set up a project. Feel free to close.

[ykakarap]

@joekr Tagged the wrong person? 😄

[ykakarap]

/close

[k8s-ci-robot]

@ykakarap: Closing this issue.

In response to this:

/close

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/test-infra repository.