Investigation: Automatic bump of controllers for releases

[yulianedyalkova]

Currently one of our biggest blockers of the fully automated releases is the bumping of controllers that needs to happen before we can create the release. Things that need to be taken into consideration:

• Which version is compatible with the next release?
• Do we always need to be behind on those?
• Can we automatically validate if we have running clusters that will break with the new controllers (if too old)?
• Can we automate the process of bumping? Even if that means creating issues for provider teams with a set date of when the next automated release creation will happen but do that early enough so that they have time to act.

Let's investigate those questions while bumping the controllers for v35.

[njuettner]

Considering the options I would propose going with a simple approach, leaving this to teams and just create an issue to all provider teams.

1. Automatically create issues for provider teams when a major release PR is created

• After the major release PR is created we create one issue per provider team and moving it to the team board
• The issue tells the team something like "Release vXX.0.0 (K8s 1.XX) is being prepared — please verify and bump your controllers"
• A comment is posted on the release PR listing all created issues with their status

2. Skip weekly bumps during development stage

• We extend to skip automatic bump apps and components in stage/development which avoids noisy/premature bumps before controller teams are ready
• Once the release moves to stage/active we're going back to normal

3. Watch for issue closure and trigger a bump

• A schedules workflow or event watcher in the PR tracks comment for linked controller-readiness issues and maybe also send us a message into our Slack team channel
• When all issues are closed, we run /update-release on the release PR to pick up the new controller versions