Add script for generating release notes automatically #91
Conversation
git-diff(1) is used to track which changes were made, so that we only check the required submodules. To take submodule changes, a match against git-ls-tree(1) output is done to retrieve the first commit in the submodule in the specified top-level range. An alternative (and simpler) approach to take the same information is to use `git-diff --submodule=log` option and parse the "Submodule" lines, but this is not known to be stable. The first commmit is used to get tags created since then until HEAD, using git-tag(1) API. This simplification of using HEAD can be easily removed, to allow arbitrary past ranges.
scripts/release.sh
Outdated
| compare_url=$github_url/$module/compare/$start_commit..$end_commit | ||
|
|
||
| if [ ${#tags[@]} -gt 0 ]; then | ||
| echo "* [$module]($compare_url) [${tags[@]}]($release_notes_url#${tags[-1],,})" |
There was a problem hiding this comment.
Note that here I'm using a pattern for the anchor that is not compatible with existing release notes from submodules. I'm assuming we could change to a simpler header which is only the tag.
It seems feasible to download the corresponding release file and get the header from that. But the same algorithm for reducing that into an anchor would need to be implemented here. I'm not sure if we'd like to do that.
|
An example of the generated note is available at #89, and can be seen rendered here. |
|
I have only quickly looked through the script, but I think it looks good and I like the output. I am not sure it should do the compare versions link for a newly added module, though. Maybe it could just be just link to the repo? |
That seems nice for me. |
The included sections are modules released, untagged updates and new modules. Commits are taken only from the diff range, so that it can also be used for generating releases from arbitrary commit ranges. Released modules are the ones that were git-tagged in the release commit range. Such modules have well-defined release notes that document the changes, which are linked. On the other hand, modules with untagged changes do not necessarily have partial release notes, so only their changeset is linked instead. New modules are listed in a separate section to make clear they weren't previously available. A direct link to the repository is provided along with release note links if applicable. A 'removed modules' section could be also created. However, an unexpected behavior of git-diff(1) is that it does not include removed submodules in its output. Thus, another approach should be taken for that.
henriquesimoes
force-pushed
the
release-script
branch
from
29a99a1
to
bb5d84e
Compare
Based on a collaboration meeting discussion, I've written a script to generate the release notes for arbitrary tags (actually, commits) from this top-level repository with proper links for corresponding release notes. The generated sections are the following:
git-taged in the release commit range. Such modules have well-defined release notes that document the changes, which are linked¹.A "removed modules" section could be also created. However, an unexpected behavior of
git-diff(1)is that it does not include removed submodules in its output. Thus, another approach should be taken for that.I decided to script that in bash, since it is basically a manipulation of several
gitcommands. Let me know if you think that might become a maintainability issue.