You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been studying the approaches of Ethereum’s EIP-BOT it can achieve our desired goal but I don’t feel like this is the right approach the reason for.
It’s relays on multiple workflow triggers;
When the pull_request_review event trigger. It runs a dummy workflow that does nothing. Also does not contain any credentials. The only reason we do have this action is to trigger another workflow base on the workflow_run event.
The custom workflow does not have the context of origin even parameters.(pull_request number, author, etc) but it has access to credentials (GitHub secrets)
The custom workflow does require logic which is pretty much the same as having Github App Bot code.
It’s hella difficult to test. Each time when we wanna test we need to real GitHub events by actually adding a Review to PR.
It still has the cold start problem as the existing Github Actions about a 2-3 minute delay for each.
What is the feature you would like to see ?
Instead, I would like us to start with Github App as an MVP feature for handling this task solely.
It has no cold start issue. We will have a Webhook event listener who will listen to events and act on them immediately.
Easier to write custom logic on it. As far as the current experience goes with GH actions where we had simple binary if-else operation problems in Yaml. Via bot, we can write Typescript code logic.
We can reuse the Github App in other code repositories without code duplication to another repo.
Since we will have a way to listen to events including (star, issues, discussion_comments … etc) we can actually add custom business logic to award users who are an active contributor of the repository by joining the conversation, bug reporting, staring the Repository, etc.)
The issue:
Currently, we have the problem of Github actions being so hard to work with.
github.head_ref
only exists in pull_request or pull_request_target.https://github.com/TheBuilderDAO/kafe/actions/runs/2168315228/workflow#L15
https://docs.github.com/en/developers/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review
I have been studying the approaches of Ethereum’s EIP-BOT it can achieve our desired goal but I don’t feel like this is the right approach the reason for.
It’s relays on multiple workflow triggers;
When the
pull_request_review
event trigger. It runs a dummy workflow that does nothing. Also does not contain any credentials. The only reason we do have this action is to trigger another workflow base on theworkflow_run
event.The custom workflow does not have the context of origin even parameters.(pull_request number, author, etc) but it has access to credentials (GitHub secrets)
The custom workflow does require logic which is pretty much the same as having Github App Bot code.
It’s hella difficult to test. Each time when we wanna test we need to real GitHub events by actually adding a Review to PR.
It still has the cold start problem as the existing Github Actions about a 2-3 minute delay for each.
What is the feature you would like to see ?
Instead, I would like us to start with Github App as an MVP feature for handling this task solely.
It has no cold start issue. We will have a Webhook event listener who will listen to events and act on them immediately.
We can locally test and really easily developable via the TDD approach. https://probot.github.io/docs/testing/
It’s quite extendable.
https://probot.github.io/docs/webhooks/ It’s the very same events that do trigger on Github Actions.
Easier to write custom logic on it. As far as the current experience goes with GH actions where we had simple binary if-else operation problems in Yaml. Via bot, we can write Typescript code logic.
We can reuse the Github App in other code repositories without code duplication to another repo.
Since we will have a way to listen to events including (star, issues, discussion_comments … etc) we can actually add custom business logic to award users who are an active contributor of the repository by joining the conversation, bug reporting, staring the Repository, etc.)
We can deploy the bot event processor as part of the Kafe Nextjs app https://probot.github.io/docs/deployment/#vercel
https://probot.github.io/docs/simulating-webhooks/ we can simulate different edge case scenarios during the development so we won’t be making noise in the GitHub Commits, and Pull requests.
The text was updated successfully, but these errors were encountered: