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

Incorrect range of commits picked up #8

Open
Smjert opened this issue Jun 11, 2024 · 2 comments
Open

Incorrect range of commits picked up #8

Smjert opened this issue Jun 11, 2024 · 2 comments

Comments

@Smjert
Copy link
Member

Smjert commented Jun 11, 2024

I haven't investigated too much but see this issue: osquery/osquery#8346

I have cloned the latest version and run it with go run ./cmd/release-notes --changelog CHANGELOG.md --last 5.12.1 --new 5.12.2 and indeed it puts in commits that should not be there (they are on master).

Between 5.12.1 and 5.12.2 only 2 commits exists: osquery/osquery@5.12.1...5.12.2

@Smjert
Copy link
Member Author

Smjert commented Jun 11, 2024

I have rerun the tool using my branch with the fix I did in my PR: #5, and even with that it doesn't work as it should.
It's picking up less commits:

[...]
### FIXME: Please Categorize

- CI: Fix macOS python dependencies install step (#8308) (MISSING PR for commit 2ad0ea9e15751f948dfbe9af04753bcc4290dfd3) ([#0](https://github.com/osquery/osquery/pull/0))
- Downgrade sqlite to 3.42 to prevent a regression with required columns ([#8295](https://github.com/osquery/osquery/pull/8295))
[...]

but still the incorrect ones; furthermore here I'm pointing the tool to a changelog file which is not in the osquery repo folder, but if I point to the one in the repo folder, somehow the "Downgrade sqlite to..." commit is not picked up. The fact that's not picked up is correct since that was already in 5.12.1, but I don't get why the CHANGELOG.md position should change the result.

@Smjert
Copy link
Member Author

Smjert commented Jun 11, 2024

Looking at the query done seems like master is hardcoded:

object(expression: "master") {

Not sure how to change this, but it should instead detect where each tag is located if the setting the branch name is needed, because the diff here is between two branches that are not master.

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

No branches or pull requests

1 participant