Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What am I not understanding... #270

Open
brettcurtis opened this issue May 8, 2020 · 8 comments
Open

What am I not understanding... #270

brettcurtis opened this issue May 8, 2020 · 8 comments
Labels

Comments

@brettcurtis
Copy link

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
Copy link
Member

@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
Copy link
Author

hahah ok no problem I thought i was going crazy lol

@JRagone
Copy link

JRagone commented 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
Copy link
Author

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
Copy link

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
Copy link

nekitk commented 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 [email protected] changelog --generate ...

@xetra11
Copy link

xetra11 commented Dec 20, 2020

Is this fixed?

Still have the mentioned issue with 0.17.3

@otherguy
Copy link

otherguy commented Feb 2, 2021

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants