Think about supporting the GraphQL API

[max-wittig]

Not sure, if this would be worth a separate library, but doesn't look like Gitlab will depreciate the v4 API anytime soon.

So just something to keep in mind.

https://docs.gitlab.com/ee/api/graphql/reference/index.html

[nejch]

That's funny last weekend I was hacking away locally on a branch to wrap https://github.com/graphql-python/gql with existing authentication/convenience stuff from gitlab.Gitlab 😁

IMO it would also make sense to provide a thin wrapper at least! Since gql has a DSL as well, not sure how really needs to be done on top of that.

[max-wittig]

haha nice 👍 I just saw a depreciation warning somewhere in the docs (removed from v5 API) and checked out their GraphQL stuff again. Last time I checked they only had a project list endpoint.

[irishismyname]

FWIW some of the existing REST APIs are unstable and marked for deprecation, notably Vulnerabilities and Vulnerability Findings. I'm pulling my hair out trying to develop a vulnerability report ATM because this python-gitlab doesn't support GraphQL (yet?) and the existing REST APIs are broken.

Also #2316 (comment).

[TimKnight-DWP]

In addition to whay @irishismyname posted above, they are changing how the CI_JOB_TOKEN works in GL 17.* and look to only be adding API control of "Allowlists" via the GraphQL API: https://gitlab.com/gitlab-org/gitlab/-/issues/435903

[mitar]

I think it would be nice if this library abstracted out the REST vs. GraphQL difference and one could just use the library, not caring what is used internally.

[TimKnight-DWP]

100% the end user of this library shouldn't need to worry about if it's GQL or REST, solely that they can perform a given action

[irishismyname]

I started writing a GitLab specific wrapper for gql and I have to say it has been quite a challenge to maintain backwards compatibility with this package and the REST API. The data structures can be the same if you write your query very carefully, but the field names are just slightly different (camel vs. underscore). There are some places (like vulnerability findings) where the data structure needs a bunch of logic to map the new fields back what REST would have returned because they took a very different approach to the structure (e.g., vulnerability location).

[mitar]

My take would be that the library should not try to use both APIs for the same logical endpoint, but that it should use GraphQL only for those which do not exist in REST or have very limited support in REST. Like new endpoints which are added only in GraphQL.

[TimKnight-DWP]

@mitar agreed, and as REST endpoints are deprecated those get swapped to GQL.

Specifically we'll want to add support for editign ci_job_token allowlists which I suspect will only be available on GQL in Gitlab 17: https://gitlab.com/gitlab-org/gitlab/-/issues/435903

[amai2012]

See REST API: Runner will no longer return ip_address and https://docs.gitlab.com/ee/api/runners.html states
The ip_address attribute in the response was deprecated [in GitLab 16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/415159) and will be removed in [a future version of the REST API](https://gitlab.com/gitlab-org/gitlab/-/issues/351109). This attribute will start returning an empty string in GitLab 17.0. The ipAddress attribute can be found inside the respective runner manager, currently only available through the GraphQL [CiRunnerManager type](https://docs.gitlab.com/ee/api/graphql/reference/index.html#cirunnermanager).