Knative OSS Diaries – week #17

Release preparation week means 🤯   + too many PRs, dependencies updates and branches floating around. But it was fun and everything seems to be ready for next week to actually make Knative 1.0 GA (core components).  happen! 🥳

I am completely hyped to be working with such an amazing team of engineers from different companies and with different backgrounds to name a few: @julz, @@markusthoemmes, @dprotaso, @bmo, @n3wscott and @argent had been fundamental in pushing this release out.

To sum up, what has been going on this week in just a few bullet points I can say the following:

• It is fundamental to read at least 20 times the release repository guide: http://github.com/knative/release
• The engineers in charge of the release choose to do the release following this approach:
  • The Github release name will be: v1.0, this require to create a branch called release-1.0
  • If the release name is v1.0 all the artifacts generated will be tagged with that version, that is containers and Kubernetes manifests
  • For Go Modules the internal version is going to be v0.27 as moving a Go module to v1.0 has proben to be more restrictive than what is needed. Interesting enough, this is the approach that is followed by Kubernetes Clients, with the difference that Kubernetes public version and go modules version follow the same numbering (0.22.3 for go modules like kubectl and 1.22.3 for github releases )
  • This change the way in how releases needs to be cut and it will be the first Knative release to have different versions for Go Modules and for the artifacts generated by the release.
  • In order to make this work, buoy a key component to check that different Knative modules are aligned needed to be updated to understand the release version v1.0 and the go modules versions v0.27 and all the automation using buoy require updating, which takes me to the next point

• CI Automation around Knative (as far as I understand it), buoy is used all over the place to check for "releasability" and syncing dependencies:
  • Knobots and Github actions are used to sync modules and validate that they are in sync
    • https://github.com/knative-sandbox/knobots/actions
    • There is a specific workflow called Update Deps and Codegen which basically runs two scripts in every Knative repository: update-deps.sh and update-codegen.sh. The trick here is that these scripts internally used a shared script that is injected by a dependency that all projects have called "hack" (library.sh and codegen-library.sh)
    • These scritps will run in each repository to update libraries and code that needs to be generated and then they will send PRs to all the repositories that are consuming the current module as a dependency.
  • Prow runs the serious stuff, creating tags and releases in github when everything is ready

For this particular release, we (thanks @n3wscott for the PR) changed buoy behaviour to understand also --module-release which is the Go mod version for the release (v0.27) which basically pushed us to change the scripts in hack, and that forced us to manually check the dependencies in each repo to make sure that the latest version of buoy was used with the correct parameters in every repository.

KubeCon NA Playlist

You can now find all KubeCon NA presentations on Youtube and here it is mine: Tools I wish existed 3 years ago to build a SaaS Offering

https://www.youtube.com/watch?v=IVKs2rUDloU&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=10