GitHub App auth CreateGitHubTokenAsync arbitrarily picks the first installation, potentially causing auth failure

[dagood]

docker-tools/src/Microsoft.DotNet.ImageBuilder/src/OctokitClientFactory.cs

Lines 77 to 78 in c976138

	Installation? appInstallation = appInfo.Installations.FirstOrDefault()
	?? throw new InvalidOperationException(

In our Go tools, we always just take the installation ID as another auth-related parameter. We aren't using any installation listing API, so at the time we thought that if we wanted to find it automatically, we'd have to have our own mapping of org/repo -> installation ID, so we simply provide the installation ID to our tools.

I believe I encountered an error once when I used the wrong installation ID, because that installation didn't have permission for the target repository. (This might be something we're hitting with our attempt to use this feature, but I'm not set up to easily debug it.)

A few possible suggestions:

• Use Single rather than First (or something like that) to fail if there are too many installations rather than picking one arbitrarily. (But this might not support us--I'm not sure if we (still) have multiple installations.)
• Cross-reference the input target of the current operation to determine which installation to use.
• (Optionally?) Take the installation ID as an arg.
• Log the encountered installations to aid debugging when working with "real" secrets through the gloves of AzDO pipelines.

/cc @gdams

[lbussell]

Thanks for the issue, I overlooked this. I meant to address this, potentially as a follow-up, but forgot. We should probably take installation ID as a required argument.

Installations should be logged as part of the InvalidOperationException in the same line of code you linked - are you not finding that to be the case?

[dagood]

We don't actually get an InvalidOperationException--my hypothesis is that we actually have more than one installation and the wrong one is getting picked. More info (although it's just very vague exception text and a build link) in the internal issue: https://github.com/dotnet/dotnet-docker-internal/issues/7468#issuecomment-2802509376

[dagood]

In any case, adding an arg for the installation ID would let me eliminate this possibility, so that sounds like a good step. 🙂