build(release): use reno for release notes

Makefile

@@ -284,3 +284,5 @@ uninstall-crds: ## Uninstall CRDs from the K8s cluster specified in ~/.kube/conf
 manifests: ## Generates CustomResourceDefinition objects.
 	@$(MAKE) run CMD="./build/generate_crds.sh ${CONTROLLER_TOOLS_VERSION}"
 
+reno-new:
+	@$(MAKE) run CMD="reno new $(note)"

build/gorelease.sh

@@ -25,4 +25,7 @@ then
 	echo "You can generate a token here: https://github.com/settings/tokens/new"
 	exit 1
 fi
-goreleaser release --parallelism=1 --rm-dist --debug --timeout 120m
+
+reno report ./ > CHANGELOG.md
+
+goreleaser release --parallelism=1 --rm-dist --debug --timeout 120m --release-notes CHANGELOG.md

docker/build/Dockerfile

@@ -29,6 +29,10 @@ RUN git config --global --add safe.directory /go/src/github.com/kanisterio/kanis
 # Adding CRD documentation generation tool.
 RUN GOBIN=/usr/local/bin go install github.com/ahmetb/gen-crd-api-reference-docs@v0.3.0
 
+RUN apt-get update && apt-get install -y pip
+
+RUN pip install reno
+
 ENV CGO_ENABLED=0 \
     GO111MODULE="on" \
     GOROOT="/usr/local/go" \

releasenotes/README.md

@@ -0,0 +1,18 @@
+## Release notes
+
+Release notes for Kanister starting with version 0.104.0 use [https://docs.openstack.org/reno/latest/](reno)
+
+Release notes are stored in `releasenotes/notes` directory.
+
+Reno allows to generate release notes using files in the repository as opposed to generating from commit messages.
+This makes it easier to review and edit release notes.
+
+## Development flow
+
+When submitting a PR with some changes worthy of mentioning in the notes (new feature, bugfix, deprecation, update requirements),
+committer should add a new note file using `reno new <note_name>` or `make reno-new note=<note_name>`.
+New file will be created in `releasenotes/notes` directory with default template.
+Change notes should be added to this file to reflect the change and additional information such as deprecations or upgrade requirements.
+It's recommended to remove unused template fields.
+
+When reviewing a PR, a reviewer should check if there are change notes added if necessary and either request or add a new note if they have push access to the branch

releasenotes/config.yaml

@@ -0,0 +1,27 @@
+---
+collapse_pre_releases: false
+earliest_version: 0.104.0
+add_release_date: false
+stop_at_branch_base: true
+ignore_notes: []
+
+sections:
+  - [features, New Features]
+  - [fixes, Bug Fixes]
+  - [security, Security Issues]
+  - [issues, Known Issues]
+  - [upgrade, Upgrade Notes]
+  - [deprecations, Deprecations]
+  - [other, Other Notes]
+
+prelude_section_name: release_summary
+template: |
+  ---
+  release_summary:
+  features:
+  issues:
+  upgrade:
+  deprecations:
+  security:
+  fixes:
+  other: