On Tue, Feb 21, 2023 at 01:43 Allen Wittenauer <a...@apache.org> wrote:
>
>
> > 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.
Thanks for the write-up Alan. I’ll think about this a bit… it seems odd to
me that pre-commit should rely on a “system in the middle”. On the other
hand, GitHub has clearly designed their system of interaction around a web
service running on the other end of those tokens.
Just for brain-storming, what if the current use of `GITHUB_AUTH` was
replaced with a function call? This would give each step in the test-patch
lifecycle a chance to “call-back” into the auth provider mechanism and
renew its token. We could provide a “static” implementation that simply
returns the existing array, and a “refreshing” version that generates a new
token each call. This would be made intentionally pluggable, so a
personality or some other robot system could override the behavior as they
require.
What do you think?
Thanks,
Nick
>
