Good idea.

Is this a duplicate of #893?

@rrauenza if you'd be OK with env variables only, this can maybe be closed as a duplicate as Chris suggests and I can try and work on #893.

Environment variables just make sense as CLI arguments would end up passing environment variables when used in CI systems anyway (which is probably what a lot of people do with this library, like your example).

There are many issues open for CLI so maybe args can be a topic for when that gets reworked.

Yeah, that sounds reasonable.

I would need this feature now. Where would we implement the API token? As in:

curl --silent --header "Authorization: Bearer $GITLAB_API_TOKEN" ...

Aside, for clarification:

• Do we technically need the distinction between the 3 types of token?
• There is now also a project access token. Which one of the 3 tokens needs to be set in that case?

For simplicity, I'd prefer to have it like @rrauenza originally requested: A single --token option for everything, which overrides any value in configurations files. We probably also should cover --username and --password (with an optional value to allow interactive input), which as a side effect will make the container entry point unnecessary, e.g.

gitlab --url https://$CI_SERVER_HOST --token $GITLAB_API_TOKEN ...
gitlab --username $CI_DEPLOY_USER --password ...

I'll try to find out if we can read from the environment from within the argparse setup code via the defaults. To my knowledge, there is not direct way to make argparse consider environment variables (unlike click).

Yeah, click would make a lot more sense for this, which is why this has kind of stalled.
To make it a global option you would probably want to add them to the base parser here:

Then if those arguments are provided and valid you would need to override from_config() in CLI and instantiate Gitlab with the args instead:

Feel free to give it a shot :)

Do we technically need the distinction between the 3 types of token?

Different types of tokens send different headers to the API, so you need to distinguish this, see

You can get away with combining oauth and PAT like as you suggested with the bearer header instead, but I don't think it'd work for job tokens, at least according to docs. But maybe it's just not documented, should be tested.

There is now also a project access token. Which one of the 3 tokens needs to be set in that case?

This and the upcoming group access tokens are basically just personal access tokens for project/group bot users.

In the meantime, if you use this in CI, this workaround has worked well for me:

  before_script:
    - pip install --quiet python-gitlab
    - 'echo -e "[global]\ndefault=gitlab\n[gitlab]\nurl=$CI_SERVER_URL\nprivate_token=$API_TOKEN" > ~/.python-gitlab.cfg'
  script:
    - 'gitlab <args...>

or if you're not in docker:

  before_script:
    - pip install --quiet python-gitlab
    - 'echo -e "[global]\ndefault=gitlab\n[gitlab]\nurl=$CI_SERVER_URL\nprivate_token=$API_TOKEN" > gitlab.cfg'
  script:
    - 'gitlab --config-file gitlab.cfg <args...>

@bittner it does seem like there's some undocumented support for the bearer header with CI job tokens, but I wouldn't rely on it being a stable API, see below. But at least downloading job artifacts with a job token + bearer auth worked. So --token could possibly be a convenience option with no guarantees..

For more context on the matrix of different auth headers and allowed credentials they come with, you can scroll through this gitlab epic: https://gitlab.com/groups/gitlab-org/-/epics/3807 (specifically this note https://gitlab.com/groups/gitlab-org/-/epics/3807#note_374553902)