GitLab: issues matching git authors and Gitlab users

In your README.md you write that a token does not need any scope.
In GitLab, when not selecting any scope, it seems to get all scopes but lets be as restrictive as possible.

I tried several scopes with role guest, but none worked.
I always get

INFO    -  git-committers: fetching contributors for docs/index.md
ERROR   -  git-committers: error fetching contributors for docs/index.md
ERROR   -  git-committers:   401 Unauthorized - You may have exceeded the API rate limit or need to be authorized. You can set a token under 'token' mkdocs.yml config or MKDOCS_GIT_COMMITTERS_APIKEY environment
           variable.

The scopes I tried (independently) are

api
read_api
read_repository

Of course I always did a

export MKDOCS_GIT_COMMITTERS_APIKEY="<token>"

I am using mkdocs-material and set

plugins:
  - git-committers:
      repository: '<private repo slug>'
      branch: master

So what scope is actually required to get it working?

Greetings 👋
For GitLab, a project access token scoped to read_api is expected to work.
That way, the token is limited to the project and has access to read the repository.
What kind of token did you use?

Hi @ojacques, I tried different project access tokens as mentioned above, one of them had read_api but weirdly it failed with the mentioned errors. What about the required minimum role for the token?

EDIT:

Just tried again with api_read token and role Maintainer but it failed again with the same error.

What about the required minimum role for the token?

In GitLab, it must at least be a developer role, as guest does not give access to the repository.
I tried with a private GitLab repo again with a project token, and it works on my end.

You mention earlier that you used:

plugins:
  - git-committers:
      repository: '<private repo slug>'
      branch: master

Where for GitLab, it should be:

plugins:
  - git-committers:
      gitlab_repository: 12345678

With the GitLab project ID, not a repo slug, like on GitHub.

Could this be the isue ?

I just realized that it is also mentioned in the README.md (https://github.com/ojacques/mkdocs-git-committers-plugin-2#setup)... sorry for not realizing that.

While it now fetches the contributors it somehow resolves it incorrectly. The person happens to have the same name than I have but obviously a different login.

Another thing came to my mind:
Why using api calls instead of local commands relying on git commands?

Glad you passed 401! 🥳

While it now fetches the contributors it somehow resolves it incorrectly. The person happens to have the same name than I have but obviously a different login.

Interesting. Do you have an example repository, or maybe share the 2 GitLab user names? I expect the API call to be deterministic and avoid such confusion.

Why using api calls instead of local commands relying on git commands?

To exactly avoid the problem you are experiencing now: not being deterministic if only based on Git commits authors which are free form. Using local git commit info was the initial implementation, but turned out to not be reliable, no matter which key was used (name, email).

This is why I'm interested in your case, as I expect that the API calls are supposed to fetch reliably the GitHub/GitLab author.

My gitlab login is skwde and the one I am being confused with is hakanabitur.

If this does not help you, I can create an example repository to share with you.

A private repo would be great indeed. Thank you.

Ok I now created the repository. What is your gitlab login such that I can give you access to the repo.

@skwde : https://gitlab.com/ojacques2

I just gave you developer access to the test repo.

…

On 26 Jan 2024, at 14:35, Olivier Jacques ***@***.***> wrote: @skwde : https://gitlab.com/ojacques2 — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

@skwde, I reproduced the issue of user mismatch (I updated the title of this issue). It is caused by the method used to find the Gitlab user. https://github.com/ojacques/mkdocs-git-committers-plugin-2/blob/master/mkdocs_git_committers_plugin_2/plugin.py#L125

Unfortunately, Gitlab API does not give us a reliable way to match commit and users (unlike GitHub). See https://gitlab.com/gitlab-org/gitlab/-/issues/20924

I tried a different way by first fetching all Gitlab project members, then look through those. But the member details (https://gitlab.com/api/v4/projects/54265429/members/all):

Don't correspond to the details I can get from a commit (https://gitlab.com/api/v4/projects/54265429/repository/commits?path=README.md&ref_name=master):

(I pixelated the actual names, but as you will see if you try / they do not match, and I could not find an ID to reliably match).
This is because Gitlab only saves the Git author information (the one you configure with "git config"), and if those don't match with the info in Gitlab, there is a possible discrepancy.

Not sure how I can take it from there...

@ojacques, you are right. The problem is that the profile is necessarily empty (like mine), consequently there is currently no reliable way to match a user to a commit until the gitlab issue (https://gitlab.com/gitlab-org/gitlab/-/issues/20924) you already linked above is resolved via adding additional info to the commits api.

A way around, until this is resolved from gitlab side, would be to make a note that in the gitlab profile name / public_email should be set to the Name / email used to commit. In that way https://docs.gitlab.com/ee/api/users.html#for-user can be used with the uid from https://docs.gitlab.com/ee/api/members.html#list-all-members-of-a-group-or-project which finally provides a match to the commits api return via name / email.
If still noting is set, maybe just issue a warning and fallback to the local info and just fetch the avatar?

Greetings 👋 For GitLab, a project access token scoped to read_api is expected to work. That way, the token is limited to the project and has access to read the repository. What kind of token did you use?

Hello @ojacques ,

Thanks! It should be on readme IMHO.

I added a note in the README that matching may not be reliable on GitLab (less of an issue on self-hosted GitLab where users are identified with SSO).
@Guts - good point! Also added a note in the README on token to use.

Thanks you!