Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEATURE REQUEST] Accept a env variable at the config for token #61

Open
cherryramatisdev opened this issue Apr 21, 2024 · 7 comments
Open

Comments

@cherryramatisdev
Copy link

This will mostly help people that uses more than one account in github and constantly switch tokens, today I'm being forced to maintain it manually like the following:

[prr]
# personal accountn
token = "token_here_personal"
# work account
# token = "token_here_work"
workdir = "/tmp/"

Maybe we could accept something simple like:

[prr]
token = "$ENV_VAR_HERE"

And parse it checking for the $ prefix? Or maybe create another field token_var if it's easier to check.

I'm willing to develop a PR for this feature! Just want to chat about it first

@cherryramatisdev cherryramatisdev changed the title Accept a env variable at the config for token [FEATURE REQUEST] Accept a env variable at the config for token Apr 21, 2024
@danobi
Copy link
Owner

danobi commented Apr 23, 2024

Hi, thanks for the request! Does the existing local config file feature help for your use case? https://doc.dxuuu.xyz/prr/config.html#local-configuration

@cherryramatisdev
Copy link
Author

Kind off, for my specific use case that is managing multiple github accounts, it's far more ergonomic to just listen to a common env var every time I execute the command

Because today I already can change my token and keep an env var synced

@danobi
Copy link
Owner

danobi commented Apr 24, 2024

Just to be clear, I was suggesting that you could keep per-account override files in your relevant project directories.

Assuming you have some kind of shell script that changes env vars around, maybe you could use that infra to call prr with different --config flags?

I'm a bit reluctant to add env var interpolation to the config file. We'd have to find a way to deal with escaping then. Another option would be to go 12-factor app style and accept all configs via env var. But that feels a bit overkill given we already have some primitives for per-repo/project overrides.

@cherryramatisdev
Copy link
Author

yeah it makes a lot of sense, I'll further look into it and post the results here, thanks a lot!!!

@lorenzleutgeb
Copy link

lorenzleutgeb commented Jun 14, 2024

I think GH_TOKEN/GITHUB_TOKEN, GH_ENTERPRISE_TOKEN/GITHUB_ENTERPRISE_TOKEN, and GH_HOST are sufficiently prominent to support: https://cli.github.com/manual/gh_help_environment

Also, if gh is available, you could use it.

@jackielii
Copy link

Here is my use case: I commit most of my configs to a public github repo and keep all the tokens in one file called .secret and encrypt it before pushing. (using Yadm). I also use direnv to keep my gitconfig & GITHUB_TOKEN separate between directories. E.g. as soon as I cd into my ~/work directory, my git and gh automatically use my work account. E.g. my ~/work/.envrc has these two lines:

export GITHUB_TOKEN=${WORK_GITHUB_TOKEN}
export GIT_CONFIG_GLOBAL=$(pwd)/.gitconfig

I can use the local configuration suggested by @danobi , but it still require me to put the secret in the config file.

Looking at the config, I think the token should definitely come from env, the workdir should default to $XDG_DATA_HOME? The activate_pr_metadata_experiment definitely stays in the config.

Maybe just add respect GITHUB_TOKEN if it's presented in env, and it would override the config?

@danobi
Copy link
Owner

danobi commented Aug 8, 2024

I think I've come around on this. For sensitive things like tokens, env var seems standard. Let's special case it. Using the prominent GH env vars makes sense to me.

Please feel free to send a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants