Authentication options (for Github Enterprise and other platforms support)

[dominykas]

While we don't need to focus on this right now, I'm opening up this discussion early, so that people can share their thoughts and things they've seen in the wild.

To implement #6, there will be a need to have at least two tokens - one for public GH, one for GH Enterprise, which means that just the GITHUB_TOKEN environment variable will not be enough.

Does anyone have any preferred solutions for that?

I personally have either used or have seen the following in the wild:

• Have a GITHUB_COM_TOKEN and have a secondary env var token. Renovate takes this approach (they use a RENOVATE_TOKEN and GITHUB_COM_TOKEN).
  • I'm personally a bit torn about this approach. I think it is critical to be able to provide all secrets via environment variables, because that's just a more common approach in different ways these things get run (inside containers, in k8s clusters, directly on various CI platforms). However on the other hand, the logic and the naming can become confusing. Also having just the two tokens may be kind of limiting (while it's probably very rare that you'd need more than one Github Enterprise, there's talk at a client right now that we might be moving from a per-project GHE to a globally shared GHE, meaning there'll likely be an overlap period and a migration). This can be solved by having a config file mapping out which token belongs to which URL?
• "Borrow" credentials from other apps, if available. E.g. on macOS you might have git osx keychain credentials helper installed, or you could be using hub, which has credentials stored in ~/.config/hub.
  • I'm personally a bit torn about this approach as well (a recurring theme, alright). On the one hand, the right thing to do is to have separate credentials per app, and the various credentials already present were not set up for our purpose, so it's kind of shady to do that, on the other hand - it's damn nice UX. If you're on a computer, and the credentials are already available and saved, why not use them (after asking for permission once)?
• Use octokit-auth-netrc
  • In a way, this is a variation of above, but if I get it right - it was also built as a generic store standard? I do kind of like this approach, although it is likely not enough, because depending on the security requirements of where wiby will be running, it might be very inconvenient operationally to provide a single file with all the credentials. I kind of wish .netrc could point to an env var as well as provide the secret value itself...
• All of the above?

[ljharb]

Why not make the user switch the token as needed, as opposed to supporting two?

[dominykas]

Why not make the user switch the token as needed

That means you need to do separate runs against different targets, with separate configs? Sure, it's an option, but it's pretty poor UX?

[ljharb]

It kind of seems like everything should "just work" the same as if you did git clone of a repo - meaning, their git config would already be set up, and no tokens would be required?

[dominykas]

You mean rely on git, rather than Github API to push things? That's probably not a bad idea, and it would work when the tests trigger on branch updates, however that won't work for e.g. Jenkins (GH Enterprise case), because Jenkins only triggers properly on PRs, so you'd still need a token to open a PR via GH API (maybe that has changed, I think I last checked that a year ago). Not sure if public setups on GH ever run into the issue where builds only trigger on PR, rather than branch. If we think that an edge case, then maybe we can only require the token when it is needed for that.

[ljharb]

Yes. Jenkins would need whatever tokens or SSH config git itself uses, sure, but presumably the user would know how to set those up?

[dominykas]

Sure, folks who can set up Jenkins, definitely set up the git creds just fine, but just git creds is not enough to open PRs (unless you have a way to "borrow" those creds somehow), i.e. you still need the two env vars or something similar (if you're going to use a mix of public/private GH instances).

Maybe we could stick to GITHUB_TOKEN for public GH, and explicitly include the name of the env var for the instances via wiby.json (designing a way to pass that via command line might be tricky, but also not impossible - ideally I'd like every wiby.json option be available via CLI directly).

[ljharb]

ahhh, ok thanks for clearing that up - i didn't think about opening PRs. However, it seems like rather than a user's token, we'd want a github app to do it?

[dominykas]

Honestly, I have no clue how apps are meant to work on standalone Enterprise instances... The one I've seen, most certainly does not have any apps that I could see as a user.

That said, I think there's lots of value in making everything accessible via CLI - apps imply asking for permissions in organizations, installation, lifecycles, etc. A nice tool should also just work locally, on a developer machine.

[dominykas]

Also opened this discussion: nodejs/tooling#87