Repository navigation
What am I not understanding... #270
Description
Please tell me why I'm not getting my second release and what from the docs am I missing??
git tag 1.0
git push origin --tags
gren release
✔ 1.0 has been successfully created!
Now I make some change in the repo, commit & push..
git tag 1.1
git push origin --tags
gren release
Getting gren config from local file /home/brett/repos/my-org/terraform-google-billing-budget/.grenrc
🤖 - Generate release notes:
===================================
✔ Releases found: 1
✔ Tags found: 1.0, 1.1
✔ Issues found: 5
Skipping 1.0 (use --override to replace it)
I would expect this to create the 1.1 release for me???
Activity
alexcanessa commentedon May 11, 2020
@brettcurtis your expectation is correct and it should get the 1.1 done. I think this is related to a "fix" that has been published recently as this has never been a problem (obviously as it's quite critical 😂).
I'll have a look into this.
brettcurtis commentedon May 11, 2020
hahah ok no problem I thought i was going crazy lol
JRagone commentedon Jun 18, 2020
Any updates on this? I'm running into the same issue through the same steps as Brett, and my sort-of workaround was to use
gren release --tags=<tag name>. For some reason though, that creates a new release with all the data sources that have ever been pushed to the branch. I might just be misunderstanding the commands, but is there any documented workaround for Brett's issue?I should probably mention that my current workaround for the workaround I just mentioned is to then run
gren release --tags=<tag name> --override, as that seems to fix the contents of the release. I'm not sure if this is a separate issue or perhaps I'm misusing commands.brettcurtis commentedon Jul 1, 2020
Thanks @JRagone - I hit this issue again and your workaround (gren release --tags= --override) is doing what I need it to until the bug is addressed.
davehensley commentedon Jul 9, 2020
I just ran into this as well. Both issues are caused by the fact that a tag has a null date until/unless it is associated with a published release, but gren sorts the tags by date in reverse order, putting the null(s) at the bottom of the list.
So let's say you just created a tag called
1.2and now you want to create a release for it. The list of sorted-by-date tags now looks like this (for clarity I omitted theidproperty and used pseudocode for the dates):If you were to run
gren release, it would see the pre-existing1.1as the first tag in the list and think you want to edit its release (which it won't do without-o) instead of creating a new release for1.2(this is issue 1).To work around that, you run
gren release -t 1.2instead. Sure enough, gren finds the1.2tag in the sorted list, with a null date, so now it wants to compose the changelog, so it looks for the date on the tag that comes immediately after it in the sorted list. Well, anything that comes after that tag will also have a null date, so it ends up building the changelog out of all of the changes that have been made since the epoch (issue 2).There are a few ways to solve it. You could force the date on the specified tag always to be "now", so it goes to the top of the list, but that would only help if you specified the tag on the command line, so it would only solve issue 2. Maybe a better solution would be to sort by the tag name instead of date (using semver sorting), filtering by what was specified in
-pto avoid non-versioning tags?nekitk commentedon Jul 10, 2020
another way to solve it is to use the last working version. we are using 0.17.1 for now via npx:
npx github-release-notes@0.17.1 changelog --generate ...xetra11 commentedon Dec 20, 2020
Is this fixed?
Still have the mentioned issue with 0.17.3
otherguy commentedon Feb 2, 2021
@xetra11 same issue here. Gren also doesn't find all tags, just 2 of them: