Repository navigation
Group import fails when parent_id is passed as int #2506
Description
Activity
Thanks for the report @vlizanae.
Regarding the confusing naming, this is really GitLab's behavior so i think we will want to keep it as is (we're just passing this to the API, so it's up to GitLab to accept IDs or url-encoded paths).
For your proposal to work, we would have to add another GET call inside the method, to find out the group's ID from the path, but as a library we really want to just be a thin wrapper around existing endpoints. If you want this behavior I'd write a little wrapper function to do so. Does that work for yo.u?
From experience, when <something>_id is passed as a parameter, it usually is only the ID, whereas as part of the URL itself it usually accepts both. As we state in the docs (https://python-gitlab.readthedocs.io/en/stable/api-usage.html), we encourage users to check upstream docs for attribute specifics, it would be too much work for us to try and mirror the upstream docs here reliably.
But the integer encoding issue is definitely a bug, we'll have to fix that, thanks again for the catch!
Reacted by Max Wittig- changed the title [-]Group import unintuitive parent_id format[/-] [+]Group import fails when parent_id is passed as int[/+] on Mar 4, 2023
Hmm I didn't realize that passing the path as id was part of gitlab's API, I thought it was a feature of the library. I agree with just replicating the behavior of the API so it's ok having just the numerical id.
Reacted by Nejc HabjanI thought I'd propose a fix upstream in requests-toolbelt but they seem to deliberately not coerce to strings: requests/toolbelt#99.
So will need to be done on our side.
- added a commit that references this issue on Mar 12, 2023
- added a commit that references this issue on Mar 12, 2023
- locked as resolved and limited conversation to collaborators on Mar 18, 2024
Description of the problem, including code/CLI snippet
Testing group export/import between different Gitlab instances. Used to the path of the group working as the group id, I tried the following:
which yields
Not very descriptive but reading gitlab's api docs I find out:
So I try the numerical id of the group:
even worse:
Expected Behavior
Because the path works as an id in several calls (e.g. groups.get) I think the first version should work. The second version should definitely work.
Actual Behavior
In the end, after digging a bit on the code, what works is:
Specifications