search

adamtabrams / change

A simple tool that automates generating and updating a changelog
GNU General Public License v3.0
75 stars 8 forks source link

Problem with patch version > 9 #19

Closed jguiditta closed 2 years ago

jguiditta commented 2 years ago

Description I recently tagged a project with an x.x.10 version, and found that calling 'change' after 'change --init' as usual resulted in 'no new versions to add'. Removing the local tag and trying again, I found that it once more worked.

Expectation I should be able to tag a patch version greater than 9

Replication

  1. Add a patch version of x.x.10
  2. run 'change --init' and then 'change'
  3. CHANGELOG.md will contain only what was added in the --init call, which should be the first tagged version in your repo
adamtabrams commented 2 years ago

@jguiditta Is this for a project that doesn't yet have a changelog, and you want to create one? If so, how many version tags exists and are there any fix: or feat: commits since the most recent version tag?

jguiditta commented 2 years ago

We have been using this tool for a little while, but slightly differently than your explained use case where change does a whole workflow. We have it generate a new changelog via CI each time our automation builds a release (which is each commit for test repo and documentation, each tag for production). We don't, at least yet, use any of the feat: or other keywords in the commits, so the changelog is pretty simple, just a list of commit summaries grouped by tag. However, I just checked the content of the commit message again, and the summary sentence does start with the word Fix (not followed by colon), perhaps this is getting picked up anyway?

adamtabrams commented 2 years ago

Is there a specific reason why you "generate a new changelog via CI each time" instead of initially create it in the repo and just have CICD update it?

Also, I'm still trying to replicate this issue. Would you be willing to post the git log for the project where this is happening? git log --oneline -20 You could certainly remove any non-public info from the output. Seeing some of the actual commit messages and tags would be very helpful.

jguiditta commented 2 years ago

Yes, we generate the changelog because I don't want a commit just for changelog changes, nor do I want a step for developers to have to remember to this as part of the release process. The overall reasoning is to have the entire pipeline as automated as possible. We do not have team buy-in on the commits containing tags, so I am using your tool in a somewhat limited capacity to aid in my overall goal. Here is the gitlog:

0f55576 (tag: 0.0.10) Fix setup.cfg to use markdown files.
ad29131 (tag: 0.0.9) Add auto-publishing and changelog generation.
f7b0b9e Update mergify config to use queue instead of merge.
6bead80 Add function to generate cryptographic hash of a list of strings.
ec62540 Add missing 'dev' target to the Makefile
1ddf497 Convert toolchest to use same packaging as our other projects.
c59f235 Switch CI over to use Github Actions.
fb01294 Fix doc generation for yaml.py
05153c3 Fix documentation on rtd.
b5ef6bb (tag: 0.0.8) Bump release to 0.0.8
a150227 Use LGPL not GPL
d428450 Add a few prior failing comparisons with older labelCompare
ed5de26 Deprecate dlrn_label_compare & stop wrapping it
2729acf Fix dlrn_label_compare
0efaf61 cpaas_label_compare: Update for new CPaaS rules
d23d89c (tag: 0.0.7) Bump release to 0.0.7
cf25898 Adding a write method to the yaml module.
9a448a8 Add cpaas_label_compare
14a6752 Enable testing with py38/py39
fa10b2e Fix tox so tests pass.

Thanks for looking at this!

jguiditta commented 2 years ago

Note, I had to edit the gitlog because I was experimenting with my local checkout to see what would happen with different variation of tags

adamtabrams commented 2 years ago

I've created a couple test cases to try replicating the problem, but I'm not seeing the behavior you described. I did think of another factor that could be the cause of what you're seeing though. Would you check to see what tags are present in github (or whichever alternative you might be using)? If your 0.0.10 tag was only added locally and hasn't been pushed to the remote repo, then info for that version wouldn't be added by the steps you're following. If you find that the tag only exists locally, you can push it to the remote with this: git push origin --tags

jguiditta commented 2 years ago

I just double-checked, and the 0.0.10 tag is present both in my local checkout and on the github remote, and I am able to replicate the behavior in both places. I don't see how the presence or lack thereof of a remote tag would affect running change locally though, unless it is doing something I was not aware of. I just spent a little time trying to pin down how to reproduce and recover from this issue. I found that (local only), I got the following results:

In all cases, I take the following steps:

rm CHANGELOG.md
change --init
change

I thought I would send these details in case they are helpful, my next step it to create a test repo on github where I can put some dummy commits and tags and see if I can reproduce there following these same steps. I will add another comment once I see if I can reproduce on a clean repository.

jguiditta commented 2 years ago

OK, following up. I created a new github repo to test this and was able to reproduce. I took the following steps:

The failure result is the same as I originally described. The --init runs fine, the subsequent 'change' call does not add commits from tags 0.0.2 or 0.0.10, and outputs 'no new versions to add'. Hope that makes it easier to reproduce.

adamtabrams commented 2 years ago

Thanks to your most recent comment, I was able to reproduce the problem. Looks like one of the regular expressions was matching the substring of the wrong version (ex 0.0.1 matched to 0.0.10). I've added a test case to make sure this won't happen and fixed the code as well. Would you mind trying this branch and letting me know if it fixes the problem before I merge the changes in?

jguiditta commented 2 years ago

OK, I just tested that branch against the local checkouts of both my test repo and the original repo, and the changelog seems to generate correctly! Thanks for the quick turnaround on this!

adamtabrams commented 2 years ago

The fix is all merged in now and the new release is tagged.

jguiditta commented 2 years ago

Great, thanks so much for getting that out so quick!