Support GH App Installation Access

[tgoodsell-tempus]

GH App Installations have a much larger API quota compared with user PATs.

Would be nice if this supported natively authing as a GH app installation and using that access token.

Docs: https://docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/authenticating-as-a-github-app-installation

[tgoodsell-tempus]

Relevant golang lib: https://github.com/bradleyfalzon/ghinstallation

[marco-m-pix4d]

@tgoodsell-tempus Ah, I never though about that!
I am not very familiar with GH Apps. My first reaction is: would that work also considering that cogito is very transient (container lifetime is < 10 sec) and many instances can exist at the same time in a Concourse installation?
Or am I misunderstanding your idea?

[tgoodsell-tempus]

@marco-m-pix4d Yes, provided you treat it similar to the PAT where you just have the end user provide all of the:

• App ID
• Installation ID
• App Private Key
• Org ID

A really basic code example for setting up the GH golang client to use this would be:

tr := http.DefaultTransport
transport, err := ghinstallation.New(tr, "USER-APP-ID", "USER-INSTALL-ID", []byte("USER-APP-PRIVATE-KEY"))
if err != nil {
	return nil, org, err
}
client := github.NewClient(&http.Client{Transport: transport})

Just treat it as an alternative to the PAT. I don't think this warrants you doing something like creating a "central" app something like a managed service that runs on a client's Github account uses to manage itself.

[marco-m-pix4d]

Just treat it as an alternative to the PAT.

Ah, I think this is the beef. Good idea, thanks! We will investigate.

EDIT: to check also what happens in case of concurrency. Currenly, we use a user PAT, and concurrency works fine. Since this is a GH "app", I wonder if GH side would do any check. This is easy to validate before going all-in in the implementation.