Think about supporting the GraphQL API

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

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.

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.

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).

@irishismyname

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

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.

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

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).

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.

@mitar

@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

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).

Hi, wanted to check in and see if there is any support planned for GraphQL. There are differences in response data between both REST and GraphQL APIs. I had raised an issue in Gitlab core to address this inconsistency but it doesn't seem like they wanna address it.

I came across this issue while looking for solutions to my REST performance issues (i.e. having to tie together multiple API calls to construct my use-case payload) - GraphQL would resolve this.

This would enable #2550 by being able to call the createWorkItem mutation

NOTE: An example of a project with a Python based GraphQL client interacting with GitLab. I think it is fairly rudimentary but I haven't looked in a lot of detail.

https://gitlab.com/cki-project/cki-lib/-/blob/7f7478b676aac97dd38b5cc6febafd0cb7604f6f/cki_lib/gitlab.py#L51-117

Can confirm the low level http_post works fine

gitlab.http_post(
    "https://gitlab.com/api/graphql",
    post_data={
        "operationName": "createWorkItem",
        "query": """
            mutation createWorkItem($input: WorkItemCreateInput!) {
                workItemCreate(input: $input) {
                    errors
                }
            }
        """,
        "variables": {}
        },
    },
)

Hey everyone!

We now have a very basic GraphQL client as of v4.11.1, built on top of gql. It's currently just a thin wrapper around gql, so you can reuse its variable injection and DSL if you like (see upstream docs). It really only handles sessions, authentication, retries and error handling so you can have a more robust library for GitLab specifically, the way you're used to from our REST client.

The next step will be to handle pagination in the client itself, but we just need to come up with an elegant way to do it. As you can see with the cki-lib linked above, there are so many ways to paginate at different levels in GraphQL, you might need to force an opinionated way of doing it to make it "generic". This is why gql itself also explicitly does not try to handle pagination AFAIK.

Regarding having an API-agnostic abstraction: based on my experience so far, the GraphQL and REST APIs are just entirely different beasts and not sure we can reliably do that here, especially as graphql can sometimes be more about efficient one-shot query building rather than writing procedural code. One thing we could probably do easily is make the data prettier by creating objects with snake_case attribute access rather than just plain dictionaries with JSON responses. If anyone has better ideas here please share!

gql does allow pre-fetching the qraphql schema or even using a local schema, and that might be interesting for validation and even maybe IDE autocompletion if we go wild, but I haven't really explored that yet. More of a follow-up issue.

If you take the new client for a spin and have any feedback just feel free to leave a comment here 🙇

I've recently used the new GraphQL support to modify the CI_JOB_TOKEN CI/CD access programmatically and after taking some time to learn how GraphQL works I must say that it seems to work quite well! Thanks a lot for this support!

One thing I ran into while working with this is that I need to specify a custom CA location to talk to the GitLab instance we're using this with and noticed that the documentation on https://python-gitlab.readthedocs.io/en/stable/api-usage-advanced.html#ssl-certificate-verification does not work for the new GraphQL client. Digging into the change of #2967 a bit I quickly noticed that the new GraphQL support in python-gitlab uses HTTPX instead of Requests and thus needs other environment variables: https://www.python-httpx.org/compatibility/#ssl-configuration

This is not a huge deal, but I'm mostly wondering: is it intended to need to set REQUESTS_CA_BUNDLE for "regular" python-gitlab requests and SSL_CERT_FILE or SSL_CERT_DIR for python-gitlab GraphQL requests? I don't think this is a huge problem when documented but I was just curious if there was an explicit reason HTTPX was chosen for GraphQL support when Requests also seemed supported and would probably cause more consistency in environment variable usage for these cases: https://gql.readthedocs.io/en/stable/transports/requests.html

But yeah, aside from this minor documentation(?) issue which is quite understandable especially for a feature clearly marked as beta it is serving me quite well so far! :)

@TheLastProject

Thanks a lot for the feedback @TheLastProject!

This is somewhat expected yes, because we're essentially relying on the behavior of underlying libraries rather than explicit configuration. You should be able to also set this programmatically if you supply your own Client to our GraphQL instance. We should definitely document this a little better!

httpx was chosen on purpose as it allows us to add an async client easily, which was a big blocker for the REST
client where we still rely on requests (see #1025, another popular request).

Since they're mostly compatible, I think in the long run we might want to switch to httpx entirely but this would also be a big breaking change. It also feels like async-compatible libraries get a little more attention in gql.

What do you think about this library that is asynchronously compatible and supports the Requests interface? Does it have any advantages over httpx?

https://github.com/jawah/niquests

@ArtemIsmagilov

What do you think about this library that is asynchronously compatible and supports the Requests interface? Does it have any advantages over httpx?
* https://github.com/jawah/niquests

@ArtemIsmagilov I'm not sure it's worth switching to a third HTTP requests library at this point - httpx is also sync/async compatible and broadly behaves like requests as well. It'll actually be trivial to add an async GraphQL client using httpx now that we have basic support for it, I'll work on this in the coming weeks.

Also httpx is quite popular and maintained by the encode folks, i.e. the author of mkdocs, Django REST framework etc, so I think it's in good hands. If I missed something about the other library though just let me know!

The async part is coming with #3045, so additional feedback welcome if anyone takes it for a spin! 🙇

This issue was marked stale because it has been open 60 days with
no activity. Please remove the stale label or comment on this
issue. Otherwise, it will be closed in 15 days.

As an open-source project, we rely on community contributions to
address many of the reported issues. Without a proposed fix or
active work towards a solution it is our policy to close inactive
issues. This is documented in CONTRIBUTING.rst

How to keep this issue open:

If you are still experiencing this issue and are willing to
investigate a fix, please comment and let us know.
If you (or someone else) can propose a pull request with a
solution, that would be fantastic.
Any significant update or active discussion indicating progress
will also prevent closure.

We value your input. If you can help provide a fix, we'd be happy
to keep this issue open and support your efforts.

This is documented in CONTRIBUTING.rst
https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst

This issue was closed because it has been marked stale for 15 days
with no activity.

This open-source project relies on community contributions, and
while we value all feedback, we have a limited capacity to address
every issue without a clear path forward.

Currently, this issue hasn't received a proposed fix, and there
hasn't been recent active discussion indicating someone is planning
to work on it. To maintain a manageable backlog and focus our
efforts, we will be closing this issue for now.

This doesn't mean the issue isn't valid or important. If you or
anyone else in the community is willing to investigate and propose
a solution (e.g., by submitting a pull request), please do.

We believe that those who feel a bug is important enough to fix
should ideally be part of the solution. Your contributions are
highly welcome.

Thank you for your understanding and potential future
contributions.

This is documented in CONTRIBUTING.rst
https://github.com/python-gitlab/python-gitlab/blob/main/CONTRIBUTING.rst

Navigation Menu

Repository navigation

Think about supporting the GraphQL API #1357

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Think about supporting the GraphQL API #1357

Description

Activity

nejch commented on Mar 3, 2021

max-wittig commented on Mar 3, 2021

irishismyname commented on Jan 2, 2024

TimKnight-DWP commented on Jan 30, 2024

mitar commented on Jan 30, 2024

TimKnight-DWP commented on Jan 30, 2024

irishismyname commented on Jan 30, 2024

mitar commented on Jan 30, 2024

TimKnight-DWP commented on Feb 7, 2024

amai2012 commented on May 13, 2024

samakshkhatri-crest commented on Jun 4, 2024

des1redState commented on Jul 1, 2024

dacevedo12 commented on Jul 12, 2024

JohnVillalovos commented on Jul 17, 2024

dacevedo12 commented on Jul 17, 2024

nejch commented on Sep 14, 2024

TheLastProject commented on Sep 18, 2024

nejch commented on Sep 18, 2024

ArtemIsmagilov commented on Oct 9, 2024

nejch commented on Oct 9, 2024

nejch commented on Nov 25, 2024

github-actions commented on Jul 9, 2025

github-actions commented on Jul 24, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions