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

[cherryramatisdev]

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

[danobi]

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]

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]

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]

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

[lorenzleutgeb]

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]

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]

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.

[mattfield]

After only recently discovering prr and finding out I couldn't just re-use the same envvar definitions that other GitHub tooling would use, I thought I'd give this one a go: #75.