Repository navigation
GitLab Integration not returning username #1492
Description
Activity
Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️
Thanks for reporting!
Rather than making the additional call, git-cliff-core/src/remote/gitlab.rs just places the commit.author.name in the remote.username field.
Hmm, do you think that's the cause? Does GitLab API return anything that is relevant (i.e. any other fields that we can use for this)?
@orhun that’s my assessment from my limited knowledge of Rust. I haven’t found a single GitLab REST API call that returns a similar result as GitHub for commits. GitLab does support GraphQL which could be used instead of REST to get results in a single call. Otherwise, I believe multiple API calls would required to replicate GitHub’s functionality and allow for direct GitLab user mentions in Changelogs.
Can confirm this on git-cliff 2.13.1 — and it's worth noting that the issue persists even when a commit is successfully matched to an MR.
Here's
git cliff --contextoutput for a commit wherepr_numberis populated:{ "message": "jira links fix", "author": { "name": "Flapjack McButterpants", "email": "flapjack@example.com" }, "gitlab": { "username": "Flapjack McButterpants", "pr_title": "feat: jira links fix", "pr_number": 15, "pr_labels": [], "is_first_time": false } }The actual GitLab username is
flapjack.mcbutterpants_42, butgitlab.usernamecontains the git display name even though the MR was matched.This suggests the fix doesn't necessarily require an extra API call —
GitLabMergeRequest.author.usernamealready contains the correct value (it's fetched as part of the MR response). It just needs to be propagated to the commit'sremote.usernamefield for matched commits.For commits that can't be matched to an MR, a fallback to the Users API (
/users?search=<email>) would still be needed.#1613 might be related: we're adding a new field called
pr_authorusernameis resolved from the commit author, whereaspr_authoris the account that
opened the pull request. They can differ, so a template that wants to credit the
contributor rather than whoever the commit resolves to can preferpr_author:
Is there an existing issue for this?
Description of the bug
When generating the Changelog for a repository using the GitLab integration, the commit author is used instead of the GitLab username. This behavior is unexpected and goes against the current GitLab Integration documentation.
Steps To Reproduce
To reproduce this bug:
git-cliff:git-cliff -r .Expected behavior
The following Changelog is generated:
Screenshots / Logs
You can see that GitLab properly recognized commit 65cd6548a62a7d1e6c573726d6a358b0e0521061 as authored by a GitLab user below:
Software information
Additional context
After some investigation, it appears the GitLab commits API and GitHub commit API differ slightly in their response which git-cliff-core/src/remote/gitlab.rs doesn't properly account for. The GitHub commit API includes the
authorandcommitterwhile the GitLab commits API doesn't (and requires an additional API call). Rather than making the additional call, git-cliff-core/src/remote/gitlab.rs just places thecommit.author.namein theremote.usernamefield.