Release notes tooling

[jessiezcc]

This came up from today's productivity wg.

Need automation/tooling to keep tracking of feature changes went into repo, and to facilitate ultimate release note generation/editing per release.

[jessiezcc]

Scraping the release notes field in PRs would be a great default for the release notes :D (going to add this field to build-pipeline as well in #72) - from @bobcatfish

[adrcunha]

Repos like serving already updated the PR template to include a field for the release notes. A simple change can make it compatible with the Prow release-notes plugin, without requiring extra tools/code/etc.

https://github.com/kubernetes/test-infra/blob/master/prow/plugins/releasenote/releasenote.go

Kubernetes release notes process is described here:

https://github.com/kubernetes/community/blob/master/contributors/guide/release-notes.md

During releases, the release notes are scraped from PRs using a tool:

https://github.com/kubernetes/release/tree/master/cmd/release-notes

Sample output of the tool above: https://gist.github.com/marpaia/acfdb889f362195bb683e9e09ce196bc

@mattmoor @samodell @RichieEscarez what do you think?

/unassign yt3liu
/assign adrcunha

[adrcunha]

/cc @evankanderson

[evankanderson]

I'd like to try running the release-notes tool against e.g. the eventing repo to see the quality of the output before we enable the Prow plugin and add toil to existing workflows.

[adrcunha]

Running the tool for all commits since May 22

$ release-notes -github-org knative -github-repo eventing -requiredAuthor "" -start-sha 207df66db27c418dd9113e5e19eb5474c87898b1 -end-sha b4fd5ece38d6f7a4adb70fc679d5e75f4a6ade68

results in a markdown file in /tmp that has the following contents:

Other Notable Changes

• the configuration for the kafka CCP is now camel case (#1386, @matzew)
• ApiServerSource and CronJobSource will trace 1% of events. (#1358, @Harwayne)
• The addressable-resolver role now includes Kubernetes Services. (#1365, @Harwayne)
• There is a new KafkaChannel CRD to instantiate Kafka channels. The provisioner based Kafka channel implementation will be deprecated in 0.7. (#1261, @nachocano)
• • each *-channel-manipulator has added 'create' verb. (#1405, @vaikas-google)
• Channel provisioners (kafka, natss, gcp-pubsub and in-memory) are deprecated in 0.7. Will be removed in 0.8 (#1366, @nachocano)
• There is a new NatssChannel CRD to instantiate NATSS channels. The provisioner based NATSS channel implementation will be deprecated in 0.7. (#1327, @nachocano)
• Users are encouraged to migrate existing container sources to use template instead of image, args, env and serviceAccountName. In future release, image, args, env and serviceAccountName will be removed. (#1321, @jingweno)
• Fixes issue where the broker may drop messages with a "no TTL" error. (#1452, @mikehelmick)
• All Broker ingress and filter pods now retrieve observability config from cluster-wide ConfigMaps (normally in the knative-eventing namespace) instead of per-namespace ConfigMaps. (#1426, @grantr)
• Subscriptions can now have different Channel kinds as part of their spec.channel. E.g., "InMemoryChannel", "KafkaChannel", etc. (#1283, @nachocano)
• the webhook has been renamed to eventing-webhook, and the old webhook will scale to 0 (#1269, @matzew)
• Inline duckv1alpha1.AddressStatus instead of Addressable to be consistent with other channel like constructs. (#1407, @vaikas-google)
• The eventing-broker-filter ClusterRole in 200-broker-clusterrole.yaml needs to be re-applied. (#1295, @Harwayne)
• CRD definitions use versions instead of version. (#1547, @vaikas-google)
• NONE. (#1445, @n3wscott)
• GCP PubSub dispatcher will need to redeployed, if it was released between Set serving build test requests/limits both to 16Gb memory #1305 and this PR. (#1313, @Harwayne)
• The broker-filter deployment now exports metrics at :9090/metrics.
  The broker_ingress_messages_total metric is now called broker_events_total. The broker_ingress_dispatch_time is now called broker_dispatch_time. (#1177, @grantr)
• Pipeline resource is gone, long live Sequence (#1406, @vaikas-google)
• • Broker now has Status.TriggerChannel and Status.IngressChannel which are ObjectReferences to the underlying Channels implementing them.
  • Trigger uses said Status.- objects to create necessary Subscriptions. (#1398, @vaikas-google)
• Adds a pipeline (sequence of functions to execute in order) with an optional Reply to send results to. (#1239, @vaikas-google)
• Change the Status.Addressable to inlined: duckv1alpha1.AddressStatus
  Add inlined: eventingduck.SubscribableTypeStatus (#1359, @vaikas-google)
• The eventing-broker-ingress ClusterRole in 200-broker-clusterrole.yaml needs to be re-applied. (#1290, @Harwayne)
• Removing the resource limits (which is a hard maximum) for eventing-controller, eventing-webhook and sources-controller (#1389, @matzew)
• Introduce a ChannelTemplateSpec field which will be used to create the CRD based channels instead of provisioners.
  • Brokers using Provisioners will be marked as Deprecated (in Status field) (#1332, @vaikas-google)
• Extend CronJobSource to respect Kubernetes Resources API (#1258, @lberk)
• Traces are visible coming out of Channel dispatchers. (#1248, @Harwayne)
• the in-memory-channel.yaml is replaced by the in-memory-channel-provisioner.yaml, and there is an new in-memory-channel-crd.yaml file that contains the new CRD for the in-mem channel (#1270, @matzew)

[adrcunha]

@evankanderson please take a look at the output of the release notes tool above and let me know if it looks reasonable for our needs.

[adrcunha]

/cc @eallred-google

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[knative-housekeeping-robot]

Stale issues rot after 30 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle rotten.
Rotten issues close after an additional 30 days of inactivity.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle rotten

[chizhg]

/remove-lifecycle rotten

[knative-housekeeping-robot]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh by adding the comment /remove-lifecycle stale.
Stale issues rot after an additional 30 days of inactivity and eventually close.
If this issue is safe to close now please do so by adding the comment /close.

Send feedback to Knative Productivity Slack channel or file an issue in knative/test-infra.

/lifecycle stale

[chizhg]

/remove-lifecycle stale

[chizhg]

/lifecycle frozen

[evankanderson]

/assign @mattmoor @dprotaso

Take a look at the command in #214 (comment) and example execution in #214 (comment) and see if this would be useful to you.

[dprotaso]

looks good to me

[evankanderson]

/assign @dprotaso to update any serving release documentation to mention how to run the tool, and to remind reviewers to check the RELEASE NOTES section of PRs.

[dprotaso]

and to remind reviewers to check the RELEASE NOTES section of PRs.

K8s has a bot that forces either release notes to be entered or set to NONE.

Can we enable that?