chore(changelog) : Replace Python script with git-cliff for Changelog generation #115
Conversation
… generation Signed-off-by: Rohan Sai Buddhi <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
This looks great, thank you for this @rohansaibuddhi!
Could you please update https://github.com/kubeflow/sdk/blob/main/RELEASE.md as well?
cc @kubeflow/kubeflow-sdk-team
Makefile
Outdated
| @PREV_TAG=$$(git tag -l --sort=-creatordate | head -1); \ | ||
| CHANGELOG_FILE=CHANGELOG/CHANGELOG-$$(echo $(VERSION) | cut -d. -f1-2).md; \ | ||
| if [ -z "$$PREV_TAG" ]; then \ | ||
| GITHUB_TOKEN=$${GITHUB_TOKEN} git-cliff --tag $(VERSION) -o $$CHANGELOG_FILE; \ | ||
| elif [ -f "$$CHANGELOG_FILE" ]; then \ | ||
| GITHUB_TOKEN=$${GITHUB_TOKEN} git-cliff $$PREV_TAG..HEAD --tag $(VERSION) --prepend $$CHANGELOG_FILE; \ | ||
| else \ | ||
| GITHUB_TOKEN=$${GITHUB_TOKEN} git-cliff $$PREV_TAG..HEAD --tag $(VERSION) -o $$CHANGELOG_FILE; \ | ||
| fi |
There was a problem hiding this comment.
This will generate chnagelog for RCs, could we skip it in this case since we decided that we'll provide changelogs for stable versions only?
cc @andreyvelich
Makefile
Outdated
| sed -i.bak "s/^__version__ = \".*\"/__version__ = \"$$V_NO_V\"/" kubeflow/__init__.py && \ | ||
| rm -f kubeflow/__init__.py.bak | ||
| @uv run python scripts/gen-changelog.py --token=$${GITHUB_TOKEN} --version=$(VERSION) | ||
| @PREV_TAG=$$(git tag -l --sort=-creatordate | head -1); \ |
There was a problem hiding this comment.
What if the last tag was 0.2.1rc1, the new release 0.2.1 will only show changes since the RC, not since 0.2.0, right? Could you update it so that for stable releases we compute the previous tag from the last stable tag?
There was a problem hiding this comment.
Makes sense. This will lead to duplication of commits between the last stable tag and 0.2.1rc1, considering we do generate changelog for RCs, would that behavior be okay?
In case there is no last stable commit, it would take all commits since the first commit. Is that expected behavior? I know we do not have to deal with this edge case since we already have 0.1.0, but wanted to confirm.
| split_commits = false | ||
| commit_preprocessors = [] | ||
| protect_breaking_commits = false | ||
| commit_parsers = [ |
There was a problem hiding this comment.
Can we also skip commits for Kubeflow SDK releases, like this 46b42d0?
There was a problem hiding this comment.
would we want this to be an exact match like '^Kubeflow SDK Official Release' or something more flexible like ".*Release [0-9]". If it is the former, we should probably add the convention to RELEASE.md as well, let me know what you think.
cliff.toml
Outdated
| {% endfor %} | ||
| """ | ||
| trim = true | ||
| render_always = true |
There was a problem hiding this comment.
Why do we want to render always?
There was a problem hiding this comment.
should we just skip rendering the 'Changelog [version] (date)' in the case there are no changes since the last release?
|
@kramaranya |
- updated README.md - stable release tags are generated based on changes from last stable release - removed ineligible PR types - skip commits with 'Kubeflow SDK Official Release' - added new contributors section
What this PR does / why we need it:
Replaces the python script being currently used with git-cliff.
Which issue(s) this PR fixes :
Will close the issue #99 when the PR gets merged.
Fixes #99
Checklist:
-The change closely follows the working of the Python script. In the current state of the repository, both the methods should generate the same changelog.
-Requires developers to follow "conventional commits" as mentioned in contributing.md.
-Works best with squash merges - https://git-cliff.org/docs/#how-should-i-manage-prs