Reattaching an entity to another client instance

[Haarolean]

Hi,

I've got a situation like this:

1. My app does listen to incoming webhooks, I parse the payload with an instance of a client authenticated as an app with a JWT token.
2. After that, once I realize which type of payload I have I fetch some info, like an issue from the payload and I have to do additional things which require app installation authentication.

With this approach I get stuck with an instance of GHIssue fetch via and tied to a client instance authenticated as an app, but in order to do other things I have to reauthenticate as an app installation. I couldn't find a way to do this. A dirty approach would be changing root of the issue instance's GitHubInteractiveObject, but the field is r/o.
Is there a way to do this now, am I missing something? if not, mind any suggestions? I'd suggest implementing a method to "rebind" an entity (GitHubInteractiveObject) to another provided instance of a github client. Any possible issues with that approach?

[gsmet]

Hi,

My advice would be to NOT parse the whole payload at first. Read the JSON, extract what you need and then parse the payload. That's what I'm doing.

If you don't want to bother about all this, have a look at my Quarkus GitHub App project (https://github.com/quarkiverse/quarkus-github-app), it handles all the heavy-lifting for you and doesn't require much knowledge about Quarkus. It has an extensive documentation which guides you through all the steps here: https://quarkiverse.github.io/quarkiverse-docs/quarkus-github-app/dev/index.html .

It is based on the Hub4j GitHub API for all the GitHub interactions (and you also can do GraphQL if you need to as not everything is exposed through the REST API these days).

And it supports GitHub Enterprise too.

I'll be happy to help in the discussions of the project (https://github.com/quarkiverse/quarkus-github-app/discussions) if you need help.

[Haarolean]

@gsmet I can imagine another situation in which app installation auth is not required at the moment, but later it would be depending on business logic, so the problem persists.

[gsmet]

My personal experience is that if you're dealing with webhooks, being in the context of a GitHub App with an installation is far more practical. But YMMV :).

[Haarolean]

@gsmet

I believe that there should be probably two modes of parsing the payload -- lazy and eager. So in order to do a full eager one with an app with installation I could already have the data I'd need (repo owner, repo name, etc). Otherwise, It's just really frustrating, I need to tear out a lot of data myself (in different ways for different payloads!) just to proceed to business logic.