-
Notifications
You must be signed in to change notification settings - Fork 15
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
fix: Not all commits beeing evalutated, added all option to gitlog #48
fix: Not all commits beeing evalutated, added all option to gitlog #48
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Forestsoft-de 👋
First of all: Thank you very much for your PRs, we appreciate this a lot 😊
I've decided to first focus on this one, as this is the easier one, and the other one needs a little bit more of discussion. I hope this is fine for you.
I've reviewed your changes, and left a few comments. Could you please take care of them?
In addition it would be great if we could have a test that reproduces the faulty behavior. Can you please add one?
Have a nice day,
Golo
.gitignore
Outdated
@@ -6,3 +6,4 @@ coverage/ | |||
|
|||
# OS generated files and directories | |||
.DS_Store | |||
get-next-version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be needed, if the build is run using the Makefile
, with the command make build
. Can you please revert this change?
git/commits.go
Outdated
@@ -29,7 +29,7 @@ func GetConventionalCommitTypesSinceLastRelease(repository *git.Repository) (Con | |||
} | |||
return ConventionalCommmitTypesResult{}, err | |||
} | |||
commitIterator, err := repository.Log(&git.LogOptions{From: head.Hash()}) | |||
commitIterator, err := repository.Log(&git.LogOptions{From: head.Hash(), All: true, Order: git.LogOrderCommitterTime}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to the documentation of the go-git
module using From
and Order
at the same time is incompatible. I.e., if Order
is being used, From
is ignored. So we should remove one of these. If it's actually needed, we should remove From
. If it is not needed, we should remove it.
Can you please double-check this?
I also guess that it could rely on different versions between Debian and alpline git but it didnt. The behavior was reproduceable with the debian container.
Yeah sure but you know I am the PHP guy :D For example d623a86 (HEAD -> main, origin/main, origin/HEAD) Merge pull request #10 from ForestsoftGmbH/feature/manual_deployment In this case only d623a86 and e867e66 are evaluated in the GetConventionalCommitTypesSinceLastRelease function. Unfortunately i didnt know how to reproduce this behavior in the testcase because you define the history as you expect :)
|
To somehow move this forward – could you maybe provide a repository that we can use to reproduce the behavior? Right now I'm not sure how to move on from the current status quo, since we can't reproduce things, and can not exactly tell which effect it will have if we merge this. |
@goloroden sure. I setuped an test repository and implemented the same workflow as i use for my private projects: https://github.com/ForestsoftGmbH/tnw-semver-tester/actions/runs/3295316981/jobs/5433820444 In this action i would expect the versio 0.2.1 because we have one commit with feat: and one with fix. The result is 0.1.0 as it would before in the tagged commit on main branch. BR |
Hi @Forestsoft-de 👋 Thanks a lot for setting up the example repository. Actually, the current behavior is correct:
So, it behaves as expected (and conforming to the way Semver works). |
PS: Since the software works as designed, I'm going to close this PR. |
git log --oneline 9d039d5 (HEAD -> fix/deprecated-warning, origin/fix/deprecated-warning) feat: improve the documentation
Then i would expect the version 0.2.0 :)
BR |
Why? A minor from |
Check the gitlog. There is an tag on a previous commit in main branch. And i saw it in the debugger that some commits are not handled by the get-next-version code. That was the intention of this PR. BR |
The Somehow I have the feeling that we are at cross purposes … from what I am able to understand, the history is as follows:
Was the tag created manually, or using Because, up to |
The action is running on the fix/deprecated-warning branch there is an active pull request to the main branch. 9d039d5 (HEAD -> fix/deprecated-warning, origin/fix/deprecated-warning) feat: improve the documentation If i push changes to this branch the tag is included before and as you say it should only raise the minor version to 0.2.0 Pushed a new change here: Also with feat: prefix and the version gets again 0.1.0
The tag was created manually.
Yeah you are right for the main branch but the action was executed on the fix/deprecated-warning branch. BR |
Okay, thanks for clarifying this 😊 My first approach was to clone your repository, switch to the branch you mentioned, and run $ git clone git@github.com:ForestsoftGmbH/tnw-semver-tester.git
$ git checkout fix/deprecated-warning
$ get-next-version
0.2.0 So, apparently the current version of the tool performs the right thing. PS: Can you please give this a try as well, just to double-check that I didn't to anything wrong? |
@goloroden you should check it with the docker container you provide in the action. Maybe there is something different. As i mentionied with my patch it works as expected. I already use it in multiple of my pipelines with an own fixed docker container: https://hub.docker.com/repository/docker/forestsoft/get-next-version BR |
I agree that there is something wrong, but if it works correctly locally, the issue is not in the code of the tool, but rather inside how we build / use the Docker image, is it? So, I'm not sold yet on the code change, because apparently it also works correctly without this change, just not in the Dockerized situation. And we need to figure out what causes the problem there. |
The bug is also not within the Docker image. I built the Docker image locally, and ran it against your repository, and it also produces The only thing that remains then is the way the workflow is written that uses According to our documentation, you did everything correctly (especially set the My current guess is that (for somewhat reason) your workflow is running on the wrong branch … but that's just a gut feeling, and I can not yet explain it. I'll get back to you once I have new insights. |
Okay, I've got the solution (I guess): actions/checkout#648 When using As said, this did never catch our eye before since we only ever run this on the Can you please try to provide the correct |
Hey @goloroden the ref: ${{ github.event.pull_request.head.sha }} results in: {"level":"fatal","time":1666449201,"message":"object not found"} See: https://github.com/ForestsoftGmbH/tnw-semver-tester/actions/runs/3303603725/jobs/5451727442 BR |
I've opened a PR on your repository by myself, to make some tests – could you maybe allow it to run? See ForestsoftGmbH/tnw-semver-tester#3 |
ea1cc77
to
10a108b
Compare
@goloroden it works now. Ive updated the PR to only improved example in your readme. BR |
In my case only merge commits are evalulated. I dont know why but get-next-version always decide that there are only chore commits.
After adding All: true it works.
BR
Sebastian