When we have merged_at info, just use that, because a PR's merge event commit date seems to merely be the date of the last commit, which is often very different than the date the PR was merged. #620
Conversation
…t commit date seems to merely be the date of the last commit, which is often very different than the date the PR was merged.
|
FYI: I wrote this to fix a version I installed via |
|
The problem I do experience, however, is I don't seem to be able to include a changelog for i.e. version 1.0.1 in the tag/release of 1.0.1 -- not only that, I have to tag a commit after the last pull request for that release in order to get that PR to get included. So it's almost a double catch-22, for each release I have to push a junk commit (i.e. "increment version" and tag it as v1.0.1) and then I have to push another commit with the actual CHANGELOG for that version. Then, if I want 1.0.1 to include its own changelog, I have to delete the tag locally and remotely, and reassign/re-push that tag. Am I missing something? Is there another common workflow? |
|
@skywinder thanks! Off topic, but do you know if such a thing exists for GitLab? I've moved all my stuff and am missing the features of this tool... maybe I can do some work to support other APIs... |
I'm not sure what the state of development is... it seems like this option has been considered and rejected by #617 however it solved the problem for me. Regardless, the github API appears to return events pointing to commits which are not the "merge commit," but rather the "last commit in the PR," which in my case are weeks apart. So this makes the script usable for me. Note I only use PRs, not issues, so this is not tested beyond manually running it against my own repo and getting better output.