search

emissary-ingress / emissary

open source Kubernetes-native API gateway for microservices built on the Envoy Proxy
https://www.getambassador.io
Apache License 2.0
4.34k stars 680 forks source link

release: remove change log PR friction #4584

Open LanceEa opened 1 year ago

LanceEa commented 1 year ago

Summary

The current process for maintaining a change log is manual and requires developers to include changes as part of a commit within a PR. This creates a few challenges that can slow up releases and in-general adds friction to the PR process.

  1. When multiple developers are trying to merge commits, every time someone merges it potentially makes a merge conflict. Which is frustrating as a developer and requires a whole new CI run. This can happen multiple times if many PR's are being merged.
  2. Very easy to forget to do it so requiring additional commits and CI runs
  3. Adds a step prior to RC and releases that slow up the RC/Release process
  4. Requires duplicating information in multiple places (commit messages, pr description, change log and docs) which ultimately don't end up sync'd.

All of this is faced during release, rc's and in the normal flow of development which is not fun. It causes us to race to get ours merged first so we don't have to rebase it again and fix the merge conflicts.

Goals

Proposal

I recommend that we switch to generating our change log based on the commits. This way it will no longer cause merge conflicts and will not require the release engineer to review and change anything. Instead the emphasis will be put on the commit subject and associated issues to help generate the release notes that are shipped. Then during a release the CI will auto-generate the release notes and attach them to the Github release.

There are plenty of tools available that can help with this on the CI and could be added as commit pre-hooks to catch non-compliant commit messages:

Now this does have the downside that the change log is no longer searchable within the repository but I think as a compromise we could generate a PR back into the release branch with a copy of the generated log file. If we were to do this we should probably create a change log file per release (maybe minor 2.3, 2.4, etc..).

kflynn commented 2 months ago

We need to either do this, or something like this, for Emissary 4.