> On Feb 20, 2023, at 12:14 AM, Nick Dimiduk <ndimi...@apache.org> wrote:
>
> Heya,
>
> Please forgive my ignorance on this subject. I do not have prior
> experience with GitHub APIs or the various flavors of accounts. I'm
> attempting to make use of Yetus against an installation of GitHub
> enterprise. I'd like to use pre-commit/test-patch from Pull Requests. My
> admins are strongly encouraging me toward GitHub's internal identity
> management system -- either a GitHub App or an OAuth App. The GitHub
> enterprise docs for my version are encouraging me away from the OAuth App
> type.
>
> In either case, it seems that access tokens are short-lived -- up to 10
> minutes? Larger projects have test suites that can take hours. Yetus
> accepts authentication credentials as part of process launch, and it
> appears that these credentials remain static for the lifetime of the
> process. For such a long test cycle, this won't work.
>
[NOTE: Github Actions is a bit different so for those listening it, the
rules are slightly different for it. Also, I’m doing this a bit from memory,
but should be mostly correct. haha.]
All of that is pretty much on the nose. If one wants to use Yetus
without any system in the middle (and that’s the key!), then one has to use a
Github App-style authentication given that OAuth App authentication requires a
callback…. which Yetus does not support. It also means you are limited to how
long the job can run, etc, etc.
> So, err, what am I missing? Or, how am I to manage delivering and renewing
> credentials with Yetus?
The key here is "without any system in the middle”… for CI tasks, MOST
of these systems effectively manage the Github token authentication and renewal
for Yetus. For the ASF, Jenkins actually does the token renewal at every step
{} statement (IIRC, that token must be marked as being used as a github
authentication bit in the credential store and Jenkins must have its own OAuth
App token). So that should help clear up how the token gets authed and
renewed. But then what happens during a precommit run?
Precommit isn’t in constant communication with Github during a run. It
happens at the very beginning (to deal with various git commands, figure out
pull request #s, read the subject of a PR to see if JIRA should be invoked,
etc, etc.). After that work is done, precommit will try to write Check Status
back. For short jobs, not a problem. But for long ones? Yes, that token is
totally expired and those calls will fail. So now what?
Enter github-status-recovery. If that command is run in a _new_
Jenkins step {} statement, that command will get a new token and finish writing
the status that the previously run precommit job saved off. That’s the key to
making everything work: there is an extra command that is run that knows
whether the previous writes were successful.
