What am I not understanding...

[brettcurtis]

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???

[alexcanessa]

@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]

hahah ok no problem I thought i was going crazy lol

[JRagone]

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]

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]

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.2 and now you want to create a release for it. The list of sorted-by-date tags now looks like this (for clarity I omitted the id property and used pseudocode for the dates):

[
  { "name": "1.1", "date": "today" },
  { "name: "1.0", "date": "yesterday" },
  { "name: "1.2", "date": null },
   ...any other tags that don't have corresponding releases...
]

If you were to run gren release, it would see the pre-existing 1.1 as 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 for 1.2 (this is issue 1).

To work around that, you run gren release -t 1.2 instead. Sure enough, gren finds the 1.2 tag 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 -p to avoid non-versioning tags?

[nekitk]

another way to solve it is to use the last working version. we are using 0.17.1 for now via npx:
npx [email protected] changelog --generate ...

[xetra11]

Is this fixed?

Still have the mentioned issue with 0.17.3

[otherguy]

@xetra11 same issue here. Gren also doesn't find all tags, just 2 of them:

Getting gren config from local file .grenrc.json

🤖  - Generate release notes:
===================================
✔ Releases found: 11
✔ Tags found: 1.4.0, 1.3.0
✔ Pull Requests found: 7