apache / camel-k

Apache Camel K is a lightweight integration platform, born on Kubernetes, with serverless superpowers
https://camel.apache.org/camel-k
Apache License 2.0
859 stars 344 forks source link

Automatically add release notes on github releases #354

Closed nicolaferraro closed 2 years ago

nicolaferraro commented 5 years ago

Does anyone know a smart way to automatically add features and bugfixes from commit messages at each release? Creation of release under github is currently a manual process (tag is auto-created, I create the release from that tag and I upload the generated files manually), so the list can be also generated in a text file if that's not automated.

@lburgazzoli, @rhuss, @astefanutti, @oscerd, @zregvart

astefanutti commented 5 years ago

After quick search, I've found the following (filtering Golang only):

It looks like Travis CI provides some level of support: https://docs.travis-ci.com/user/deployment/releases.

If the above is not enough, we'll have to go lower level:

rhuss commented 5 years ago

Tbh, I still collect the high-level changes manually in a top-level CHANGELOG and verify for each PR that it contains an entry in the changelog if its a relevant PR.

I experimented with auto extracting from commit message, but this requires a level of commit discipline I never ever have seen in a community project with PR contributions from the outside. Of course, one can insist on rewriting the commit messages when reviewing a PR but at the end, this was just tedious.

I have to confess that even for PRs which are missing a changelog entry, I often approve the PR to avoid yet another turnaround and edit the changelog directly on upstream master via the GitHub Web UI, adding a line to the Changelog directly.

Example of a changelog maintained this way is https://github.com/fabric8io/docker-maven-plugin/blob/master/doc/changelog.md (the links are created via a script during a release when entering I just add the plain issues/pr number without the link).

'happy to do it differently, but as mentioned, educating people to use a fixed format for the commit messages is a challenge on its own (where I've failed multiple times, think e.g. how we tried to introduce commitizen style logs in the Syndesis project).

github-actions[bot] commented 2 years ago

This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!