search

orhun / git-cliff

A highly customizable Changelog Generator that follows Conventional Commit specifications ⛰️
https://git-cliff.org
Apache License 2.0
9.18k stars 196 forks source link

Bitbucket `is_first_time` can report incorrectly #906

Open mcwarman opened 2 weeks ago

mcwarman commented 2 weeks ago

Is there an existing issue for this?

Description of the bug

The Bitbucket first time does not report correctly when a user has made a commit in another as well as there first merged contribution.

We had a scenario where a first time contributor wasn't being reported in the change log. Looking into it the Commits API from bitbucket it returns all commits across all branches.

GET /repositories/{workspace}/{repo_slug}/commits/

Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to git log --all).

The user has also made another commit in another branch which was there first commit in the repo, but not there first commit on the branch being released.

Reference: https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-get

curl https://api.bitbucket.org/2.0/repositories/<org>/<repo>/commits?include=<branch>

Steps To Reproduce

  1. New user commits and pushes branch
  2. New user commits and pushes branch for second change
  3. Merge change from item 2
  4. git-cliff --current --context --bitbucket-repo "org/repo"

Expected behavior

The is_first_time value is updated based on users contributions to the current branch (not the repo).

Screenshots / Logs

No response

Software information

Additional context

I guess the fix is to make the current branch context available in the Remote struct so it can be used in the API call.

https://github.com/orhun/git-cliff/blob/508a97edb088f77d01f232676d1e3c7f129071b2/git-cliff-core/src/remote/bitbucket.rs#L52-L58

orhun commented 2 weeks ago

Duplicate, see #891

mcwarman commented 2 weeks ago

I was looking at that one, it could be duplicate, but i think the scenarios are slightly different:

This one refers to commit in repo but not in the release effecting the users is_first_time status.

Where as I believe #891 is when a previous releases logs is_first_time status is effected, by future releases.

orhun commented 2 weeks ago

Hmm I see, I guess this one is also about using different branches and --current flag. Do you think fixing #891 would affect this in some way as well?

I guess the fix is to make the current branch context available in the Remote struct so it can be used in the API call.

This makes sense, however, we should look into other remotes (GitLab,GitHub,Gitea) to see if it is possible. Any ideas?

mcwarman commented 2 weeks ago

Looks possible according to the various docs:

I think they're all effected looking at the API documentation GitLab and GitHub is possible less obvious to users as it defaults to the default branch.

GitHub

Looks to default to the "default branch", but wouldn't work for users if they'd expect it to be running in different context.

GET /repos/{owner}/{repo}/commits

Query Parameters sha SHA or branch to start listing commits from. Default: the repository’s default branch (usually main).

https://docs.github.com/en/rest/commits/commits?apiVersion=2022-11-28#list-commits

GitLab

Looks to default to the "default branch", but wouldn't work for users if they'd expect it to be running in different context.

GET /projects/:id/repository/commits

Query Parameters ref_name The name of a repository branch, tag or revision range, or if not given the default branch

https://docs.gitlab.com/ee/api/commits.html#list-repository-commits

Gitea

Not entirely clear what the default behaviour is here from the documentation, but its either going to work like GitHub/GitLab or Bitbucket

GET /repos/{owner}/{repo}/commits

Query Parameters sha SHA or branch to start listing commits from (usually 'master')

https://docs.gitea.com/api/1.20/#tag/repository/operation/repoGetAllCommits

Bitbucket

Returns all commits in the repo in topological order (newest commit first). All branches and tags are included (similar to git log --all).

GET /repositories/{workspace}/{repo_slug}/commits

https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-get

Alternate endpoint might be better GET /repositories/{workspace}/{repo_slug}/commits/{revision}

https://developer.atlassian.com/cloud/bitbucket/rest/api-group-commits/#api-repositories-workspace-repo-slug-commits-revision-get

orhun commented 2 weeks ago

Thanks for investigating this further! Then I guess we can add a branch field to the remote and update the API usages 👍🏼

Would you be interested in working on this? My schedule is a bit tight these days (due to approaching EuroRust conference) so I might not get to it until next week.

mcwarman commented 2 weeks ago

Yeah I'd be interested, I'll try have a look, I created the scenario in the test repo here:

orhun commented 1 week ago

Awesome