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

fix: Not all commits beeing evalutated, added all option to gitlog #48

Merged
merged 2 commits into from
Oct 23, 2022

Conversation

Forestsoft-de
Copy link
Contributor

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

Copy link
Member

@goloroden goloroden left a 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
Copy link
Member

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

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?

@goloroden goloroden mentioned this pull request Oct 3, 2022
@Forestsoft-de
Copy link
Contributor Author

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

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?

Yeah sure but you know I am the PHP guy :D
I ran an debugging session with my repo and i detected that the repository.Log(&git.LogOptions{From: head.Hash()}) returns only merged commits. I saw that one of the merge commit has also a tag:

For example
git log --oneline

d623a86 (HEAD -> main, origin/main, origin/HEAD) Merge pull request #10 from ForestsoftGmbH/feature/manual_deployment
6985e3a (origin/feature/manual_deployment) fix: make it possible to redeploy an exisisting release
eb2d6b7 Trigger pipeline manually for new version
e867e66 (tag: 0.1.15) Merge pull request #9 from ForestsoftGmbH/bugfix/newversion

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 :)

Have a nice day,

Golo

@goloroden
Copy link
Member

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.

@Forestsoft-de
Copy link
Contributor Author

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

@goloroden
Copy link
Member

Hi @Forestsoft-de 👋

Thanks a lot for setting up the example repository.

Actually, the current behavior is correct:

  • Since no tag was given in the beginning, get-next-version starts with an assumed version of 0.0.0.
  • Then you merged a feat and a fix, which basically means minor and patch.
  • Since minor are allowed to include patches, the fix is not relevant here, only the feat is considered.
  • Hence the minor version is increased, and you get a 0.1.0.

So, it behaves as expected (and conforming to the way Semver works).

@goloroden
Copy link
Member

PS: Since the software works as designed, I'm going to close this PR.

@goloroden goloroden closed this Oct 21, 2022
@Forestsoft-de
Copy link
Contributor Author

Hi @Forestsoft-de 👋

Thanks a lot for setting up the example repository.

Actually, the current behavior is correct:

  • Since no tag was given in the beginning, get-next-version starts with an assumed version of 0.0.0.
    Are you sure?

git log --oneline

9d039d5 (HEAD -> fix/deprecated-warning, origin/fix/deprecated-warning) feat: improve the documentation
c5f9087 fix: documentation
2076428 (origin/main, origin/HEAD, main) Merge pull request #1 from ForestsoftGmbH/feature/github-action
0bf9f5c (tag: 0.1.0, origin/feature/github-action) fix: version constraint
38fb3fc feat: releasing this repository using action
e6428b4 Initial release

  • Then you merged a feat and a fix, which basically means minor and patch.
  • Since minor are allowed to include patches, the fix is not relevant here, only the feat is considered.

Then i would expect the version 0.2.0 :)

  • Hence the minor version is increased, and you get a 0.1.0.

So, it behaves as expected (and conforming to the way Semver works).

BR
Sebastian

@goloroden
Copy link
Member

Then i would expect the version 0.2.0 :)

Why? A minor from 0.0.0 is a 0.1.0, or am I missing something?

@Forestsoft-de
Copy link
Contributor Author

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
Sebastian

@goloroden
Copy link
Member

goloroden commented Oct 21, 2022

The 0.1.0 tag is on the third commit, and after that there is only the merge commit, which is missing a prefix, hence no new version is being generated.

Somehow I have the feeling that we are at cross purposes … from what I am able to understand, the history is as follows:

  • Initlal commit
  • feat commit
  • fix commit
  • Tag 0.1.0
  • Merge commit

Was the tag created manually, or using get-next-version?
And, at what point in time do you now try to run get-next-version and expect the 0.2.0?

Because, up to 0.1.0 there was a feat and a fix, and no previous tag, so 0.1.0 is correct.
And after the 0.1.0 tag there are no commits with any prefix, so they are ignored.

@Forestsoft-de
Copy link
Contributor Author

The 0.1.0 tag is on the third commit, and after that there is only the merge commit, which is missing a prefix, hence no new version is being generated.

Somehow I have the feeling that we are at cross purposes … from what I am able to understand, the history is as follows:

  • Initlal commit
  • feat commit
  • fix commit
  • Tag 0.1.0
  • Merge commit

The action is running on the fix/deprecated-warning branch there is an active pull request to the main branch.
On top of that last merge commit there are 2 commits:

9d039d5 (HEAD -> fix/deprecated-warning, origin/fix/deprecated-warning) feat: improve the documentation
c5f9087 fix: 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:
ForestsoftGmbH/tnw-semver-tester@ffac773

Also with feat: prefix and the version gets again 0.1.0

Was the tag created manually, or using get-next-version? And, at what point in time do you now try to run get-next-version and expect the 0.2.0?

The tag was created manually.

Because, up to 0.1.0 there was a feat and a fix, and no previous tag, so 0.1.0 is correct. And after the 0.1.0 tag there are no commits with any prefix, so they are ignored.

Yeah you are right for the main branch but the action was executed on the fix/deprecated-warning branch.

BR
Sebastian

@goloroden goloroden reopened this Oct 21, 2022
@goloroden
Copy link
Member

goloroden commented Oct 21, 2022

Okay, thanks for clarifying this 😊

My first approach was to clone your repository, switch to the branch you mentioned, and run get-next-version locally. As expected, the result is 0.2.0:

$ 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.
The question is: Why does it behave differently on GitHub?

PS: Can you please give this a try as well, just to double-check that I didn't to anything wrong?

@Forestsoft-de
Copy link
Contributor Author

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

@goloroden
Copy link
Member

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.

@goloroden
Copy link
Member

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 0.2.0.
Hmmm 🤔

The only thing that remains then is the way the workflow is written that uses get-next-version.

According to our documentation, you did everything correctly (especially set the fetch-depth parameter), but we have only ever tested this on the main branch.

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.

@goloroden
Copy link
Member

Okay, I've got the solution (I guess): actions/checkout#648

When using fetch-depth: 0 the current branch is ignored, and you always get the main branch.
You need to specify the desired branch / commit by providing ref: <...>.

As said, this did never catch our eye before since we only ever run this on the main branch.

Can you please try to provide the correct ref, and see if this fixes the issue?

@Forestsoft-de
Copy link
Contributor Author

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
Sebastian

@goloroden
Copy link
Member

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

@Forestsoft-de
Copy link
Contributor Author

Forestsoft-de commented Oct 22, 2022

@goloroden it works now.

Ive updated the PR to only improved example in your readme.

BR
Sebastian

@goloroden goloroden merged commit 3acd5fa into thenativeweb:main Oct 23, 2022
@Forestsoft-de Forestsoft-de deleted the fix/commit-history branch October 23, 2022 13:13
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

Successfully merging this pull request may close these issues.

2 participants