cli command line arguments for url and token #960

Activity

1. max-wittig commented on Dec 9, 2019

   

   max-wittig

   on Dec 9, 2019

   Member

   More actions

   Good idea.
2. max-wittig

   added

   cli

   enhancement

   on Dec 9, 2019
3. chrisoldwood commented on Jan 30, 2020

   

   chrisoldwood

   on Jan 30, 2020

   More actions

   Is this a duplicate of #893?
4. nejch commented on Feb 25, 2020

   

   nejch

   on Feb 25, 2020

   Member

   More actions

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

   👍React with 👍2Reacted by Rich Rauenzahn and Peter Bittner
5. rrauenza commented on Jul 9, 2020

   

   rrauenza

   on Jul 9, 2020

   Author

   More actions

   Yeah, that sounds reasonable.
6. bittner commented on Dec 17, 2020

   

   bittner

   on Dec 17, 2020

   Contributor

   More actions

   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).
7. nejch commented on Dec 17, 2020

   

   nejch

   on Dec 17, 2020

   Last edited by nejch

   Member

   More actions

   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:
   

   python-gitlab/gitlab/cli.py

   Lines 81 to 130 in 265dbbd

   	def _get_base_parser(add_help=True):
   	parser = argparse.ArgumentParser(
   	add_help=add_help, description="GitLab API Command Line Interface"
   	)
   	parser.add_argument("--version", help="Display the version.", action="store_true")
   	parser.add_argument(
   	"-v",
   	"--verbose",
   	"--fancy",
   	help="Verbose mode (legacy format only)",
   	action="store_true",
   	)
   	parser.add_argument(
   	"-d", "--debug", help="Debug mode (display HTTP requests)", action="store_true"
   	)
   	parser.add_argument(
   	"-c",
   	"--config-file",
   	action="append",
   	help="Configuration file to use. Can be used multiple times.",
   	)
   	parser.add_argument(
   	"-g",
   	"--gitlab",
   	help=(
   	"Which configuration section should "
   	"be used. If not defined, the default selection "
   	"will be used."
   	),
   	required=False,
   	)
   	parser.add_argument(
   	"-o",
   	"--output",
   	help="Output format (v4 only): json|legacy|yaml",
   	required=False,
   	choices=["json", "legacy", "yaml"],
   	default="legacy",
   	)
   	parser.add_argument(
   	"-f",
   	"--fields",
   	help=(
   	"Fields to display in the output (comma "
   	"separated). Not used with legacy output"
   	),
   	required=False,
   	)
   	return parser

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

   python-gitlab/gitlab/cli.py

   Line 223 in 265dbbd

   gl = gitlab.Gitlab.from_config(gitlab_id, config_files)

   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

   python-gitlab/gitlab/__init__.py

   Lines 357 to 375 in be0afdd

   	if self.private_token:
   	self.headers.pop("Authorization", None)
   	self.headers["PRIVATE-TOKEN"] = self.private_token
   	self.headers.pop("JOB-TOKEN", None)
   	if self.oauth_token:
   	self.headers["Authorization"] = "Bearer %s" % self.oauth_token
   	self.headers.pop("PRIVATE-TOKEN", None)
   	self.headers.pop("JOB-TOKEN", None)
   	if self.job_token:
   	self.headers.pop("Authorization", None)
   	self.headers.pop("PRIVATE-TOKEN", None)
   	self.headers["JOB-TOKEN"] = self.job_token
   	if self.http_username:
   	self._http_auth = requests.auth.HTTPBasicAuth(
   	self.http_username, self.http_password
   	)

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

   👍React with 👍2Reacted by Max Wittig and resister
8. nejch commented on Dec 25, 2020

   

   nejch

   on Dec 25, 2020

   Member

   More actions

   @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)
9. JohnVillalovos

   closed this as completedin #1296on Jan 2, 2022
10. github-actions

    locked as resolved and limited conversation to collaborators on Jan 9, 2023