git-cliff icon indicating copy to clipboard operation
git-cliff copied to clipboard

GitLab context data are missing

Open nqdrizzt opened this issue 1 year ago • 16 comments
trafficstars

Is there an existing issue for this?

  • [X] I have searched the existing issues

Description of the bug

While using a self hosted gitlab instance, the gitlab context of each commit is always empty like in the example bekow:

{ "id": "49bf75934a826c6d182e958405d680938bb474c3", "message": "change all input variables to lower case", "body": "Merge branch 'fix_lower_case_inputs' into 'main'", "footers": [ { "token": "Closes", "separator": " #", "value": "2", "breaking": false }, { "token": "BREAKING CHANGE", "separator": ":", "value": "change all input variables to lower case\n\nSee merge request me-and-only-me/git-cliff-changelog!2", "breaking": true } ], "group": "🐛 Bug Fixes", "breaking_description": "change all input variables to lower case\n\nSee merge request me-and-only-me/git-cliff-changelog!2", "breaking": true, "scope": "inputs", "links": [ { "text": "#2", "href": "/-/issues/2" }, { "text": "!2", "href": "/-/merge_requests/2" } ], "author": { "name": "John Snow", "email": "[email protected]", "timestamp": 1710149612 }, "committer": { "name": "John Snow", "email": "[email protected]", "timestamp": 1710149612 }, "conventional": true, "merge_commit": true, "github": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false }, "gitlab": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false }, ... ... },

git-cliff verbose output: TRACE git_cliff_core::repo > Upstream URL: https://my.gitlabinstance.com/me-and-only-me/git-cliff-changelog.git DEBUG git_cliff > No GitHub remote is set, using remote: me-and-only-me/git-cliff-changelog TRACE git_cliff > Arguments: Opt { help: None, version: None, verbose: 4, init: None, config: "/config/git-cliff.toml", workdir: None, repository: None, include_path: None, exclude_path: None, tag_pattern: None, with_commit: None, skip_commit: None, prepend: None, output: None, tag: None, bump: false, bumped_version: false, body: None, latest: false, current: false, unreleased: true, topo_order: false, no_exec: false, context: true, strip: None, sort: Newest, range: None, github_token: None, github_repo: None, gitlab_token: Some( Secret([REDACTED alloc::string::String]), ), gitlab_repo: Some( RemoteValue( Remote { owner: "me-and-only-me", repo: "git-cliff-changelog", token: None, }, ), ), bitbucket_token: None, bitbucket_repo: None, }

Steps To Reproduce

  1. install git-cliff 2.3.0 deb on debian
  2. clone repo from private gitlab instance
  3. change into repo folder
  4. run : GITLAB_API_URL=https://my.gitlabinstance.com/api/v4 git-cliff --gitlab-repo me-and-only-me/git-cliff-changelog --gitlab-token my-awesome-personal-api-token -vvvv -u -x

Expected behavior

any data in context of gitlab

"gitlab": { "username": "John Snow", "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false },

Screenshots / Logs

No response

Software information

  • Operating system: Debian 12 bookworm
  • Project version: git-cliff 2.3.0

Additional context

No response

nqdrizzt avatar Jun 10 '24 12:06 nqdrizzt

Thanks for opening your first issue at git-cliff! Be sure to follow the issue template! ⛰️

welcome[bot] avatar Jun 10 '24 12:06 welcome[bot]

@dark0dave wanna take a look into this? :)

orhun avatar Jun 10 '24 18:06 orhun

I am having this same issue on gitlab.com as well, same version of git-cliff on Linux and macOS.

trevorlauder avatar Jun 13 '24 23:06 trevorlauder

I don't have the word gitlab anywhere in my codebase:

+ : GIT_CLIFF_CONFIG: project-rp-npm/cliff.toml
+ : GIT_CLIFF_INCLUDE_PATH: 'project-rp-npm/**'
+ : GIT_CLIFF_TAG_PATTERN: 'project-rp-npm-v[0-9].*'
+ : GIT_CLIFF_IGNORE_TAGS: ''
+ : GIT_CLIFF_OUTPUT: ./project-rp-npm/CHANGELOG.LATEST.md
+ : GIT_CLIFF_PREPEND: ./project-rp-npm/CHANGELOG.md
+ test -f project-rp-npm/cliff.toml
+ test -f ./project-rp-npm/CHANGELOG.md
+ git-cliff --verbose --bump -u
 DEBUG git_cliff > Failed to get remote from GitLab repository: UrlParseError(RelativeUrlWithoutBase)
 DEBUG git_cliff_core::changelog > Processing the commits...
 DEBUG git_cliff_core::changelog > Processing the releases...

bukowabot avatar Jun 14 '24 19:06 bukowabot

Remote variables were not available in context, that is now fixed in #703 - can you build from source and test this again?

Also, I created #704 which will be useful when it comes to setting custom API URLs I think.

orhun avatar Jun 15 '24 15:06 orhun

Today i compiled git-cliff from main source. The problem still exists. the context does not have any info of a self managed gitlab instance included although it is configured:

"commits": [ { "id": "60e2453ba250276a30998c69fa1f89d6eeb1cacf", "message": "child pipelines and commit signing", "body": "Merge branch 'refactor_childpipeline' into 'master'", "footers": [ { "token": "Closes", "separator": " #", "value": "28\nSee merge request my-group/my-subgroup/my-repo!46", "breaking": false } ], "group": "🚜 Refactor", "breaking_description": null, "breaking": false, "scope": "pipeline", "links": [ { "text": "#28", "href": "/-/issues/28" }, { "text": "!46", "href": "/-/merge_requests/46" } ], "author": { "name": "John Doe", "email": "[email protected]", "timestamp": 1718809429 }, "committer": { "name": "John Doe", "email": "[email protected]", "timestamp": 1718809429 }, "conventional": true, "merge_commit": true, "github": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false }, "gitlab": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false }, "gitea": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false }, "bitbucket": { "username": null, "pr_title": null, "pr_number": null, "pr_labels": [], "is_first_time": false } } }

git-cliff verbose output of the remote part: remote: RemoteConfig { github: Remote { owner: "", repo: "", token: None, }, gitlab: Remote { owner: "my-group/my-subgroup", repo: "my-repo", token: Some( Secret([REDACTED alloc::string::String]), ), }, gitea: Remote { owner: "", repo: "", token: None, }, bitbucket: Remote { owner: "", repo: "", token: None, }, },

the remote was configured in the config file, GITLAB_TOKEN was set as environment as well as the GITLAB_API_URL

here i also stumbled over a different issue. first i configured the GITLAB_REPO also as environment variable and here i realized the the parsing of owner and repos seems to be broken. because if you have a sub group after the group, something like GITLAB_REPO =my-group/my-subgroup/my-repo, the owner was set only to my-subgroup, missing the my-group. same goes if you hand over the repo via cli argument. however, if you specify owner and repo via config file it seems to be parsed correct, as you can see above in the git-cliff verbose output

however, gitlab integration is still not availabe in the context withe the latest build from source

nqdrizzt avatar Jun 21 '24 08:06 nqdrizzt

i just tested it withe the latest release v2.4.0 version. its is still not fixed. the is no info available on any commit from a self hosted gitlab instance. gitlab details were configured via config file, token and api endpoint were handed over via environment variable.

the context does not contain any infos of the remote, and therefor also the infos are not available via template in the final changelog file

nqdrizzt avatar Jun 26 '24 12:06 nqdrizzt

@orhun This is due to self managed gitlab projects api needing an encoded path to retrieve the project information. Docs here

For self hosted instances where subgroups are managed with the logic here will likely need to be changed(I would url encode strings set by the end user in this case). In OPs case, owner is likely set like the following.

[remote]
owner = "myGroup/mySubGroup"
repo = "theRepo"

@nqdrizzt if you instead set it like this(encoding all slashes) git cliff will work as you expect.

[remote]
owner = "myGroup%2FmySubGroup"
repo = "theRepo"

tonybutt avatar Jul 03 '24 04:07 tonybutt

well, this also does not work. i executed the following command based on git-cliff 2.4.0:

I tried each possible combo specifying the gitlab configuration. config.toml contains: [remote.gitlab] owner = "my-group%2Fmy-sub-group" repo = "my-repo" token = "my-secret-token"

GITLAB_TOKEN="my-secret-token"
GITLAB_API_URL="https://my.private-gitlab.com/api/v4"
GITLAB_REPO="my-group%2Fmy-sub-group/my-repo"
git-cliff --gitlab-token my-secret-token --gitlab-repo my-group%2Fmy-sub-group/my-repo -x -v <some_range>

debug output:

TRACE git_cliff_core::repo > Upstream URL: [email protected]:my-group/my-sub-group/my-repo.git DEBUG git_cliff > Failed to get remote from GitHub repository: UrlParseError(RelativeUrlWithoutBase) TRACE git_cliff > Arguments: Opt { .... github_repo: None, gitlab_token: Some( Secret([REDACTED alloc::string::String]), ), gitlab_repo: Some( RemoteValue( Remote { owner: "my-group%2Fmy-sub-group", repo: "my-repo", token: None, }, ), ), .... .... .... remote: RemoteConfig { github: Remote { owner: "", repo: "", token: None, }, gitlab: Remote { owner: "my-group%2Fmy-sub-group", repo: "my-repo", token: Some( Secret([REDACTED alloc::string::String]), ), },

and still the context still does not contain any gitlab relevant data:

       {
            "id": "49efa63bd87439e8542ec0a07864e2605bb54048",
            "message": "fix strange yaml formatting error ",
            "body": null,
            "footers": [],
            "group": "<!-- 9 -->👷 CI/CD",
            "breaking_description": null,
            "breaking": false,
            "scope": "pipeline",
            "links": [],
            "author": {
                "name": "Me Myself",
                "email": "[email protected]",
                "timestamp": 1716334094
            },
            "committer": {
                "name": "Me Myself",
                "email": "[email protected]",
                "timestamp": 1716334094
            },
            "conventional": true,
            "merge_commit": false,
            "github": {
                "username": null,
                "pr_title": null,
                "pr_number": null,
                "pr_labels": [],
                "is_first_time": false
            },
            "gitlab": {
                "username": null,
                "pr_title": null,
                "pr_number": null,
                "pr_labels": [],
                "is_first_time": false
            },

.... },

nqdrizzt avatar Jul 03 '24 13:07 nqdrizzt

@nqdrizzt Thanks, this lead me the to actual issues and I hacked a solution.

@orhun This is missing fields in GitlabCommit and GitlabMergeRequest so serde is failing to deserialize into the type and for some reason that deserialize error is being swallowed and not being logged anywhere so this was super hard find.

tonybutt avatar Jul 04 '24 14:07 tonybutt

Hi, I was testing cliff in the context of a gitlab.com project and I think I just hit this issue. The connection to the remote project looks ok however when I print the context I'm only able to see the username like this:

      gitlab:
        username: Loic Nicolle
        pr_title: null
        pr_number: null
        pr_labels: []
        is_first_time: false

all the fields related to the PR/MR are empty. Is there a workaround/fix for that?

Loic-Nicolle avatar Jul 10 '24 13:07 Loic-Nicolle

Thanks for looking into this! @nqdrizzt @tonybutt #742 is now merged.

This is missing fields in GitlabCommit and GitlabMergeRequest so serde is failing to deserialize into the type and for some reason that deserialize error is being swallowed and not being logged anywhere so this was super hard find.

Can you share which fields are missing?

orhun avatar Jul 28 '24 06:07 orhun

I have the exact same problem with the empty attributes, and the firstname + lastname instead of the gitlab username.

@tonybutt - could you get a change to fix the deserialization issue you found?

marcaurele avatar Aug 18 '24 18:08 marcaurele

i have the same problem also but with GITHUB

JacobAmar avatar Sep 17 '24 13:09 JacobAmar

Can you share your configuration? @JacobAmar

orhun avatar Sep 18 '24 13:09 orhun

Hello, same problem here, only gitlab.username is filled

benjdl avatar Apr 23 '25 08:04 benjdl

Greetings, everyone. Could someone provide an update on the current status?

Frankly, this has been dragging on for quite some time, even though it appears to be a relatively straightforward fix. Could you please clarify the background of the issue and explain why the resolution is taking so long?

JuryA avatar Jun 21 '25 15:06 JuryA

Not sure if the fix for this issue is available tbh - I can't even reproduce this IIRC

I'll take a look at your PR

orhun avatar Jun 22 '25 16:06 orhun