Open 0x4007 opened 6 months ago
Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later.
As a heads up @wannacfuture @whilefoo
! action returned an unexpected value
! action returned an unexpected value
! action returned an unexpected value
Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later.
As a heads up @wannacfuture @whilefoo
Is it okay to make bot to respond about the events on config repo?
! action returned an unexpected value
Turns out we don't need PATs at all if the bot is installed on both repositories. Will update this specification to reflect this later. Source. As a heads up @wannacfuture @whilefoo
Is it okay to make bot to respond about the events on config repo?
I don't understand your question.
You want to install bot on both repositories -> the user's repo and the config repo for compute delegating.
So the bot will react to the events on config repo as well.
Like I said here we would need another github app just for plugins because it needs additional permissions that we don't need for partner repos. Also when the compute finishes you can't use Github app to trigger an event on calling repo because you're now in the context of plugin's repo, so like I recommended it would be better to just trigger an event on the plugin repo itself
Like I said here we would need another github app just for plugins because it needs additional permissions that we don't need for partner repos.
We can enable workflow write permissions on our app. There's no issue with that.
Also when the compute finishes you can't use Github app to trigger an event on calling repo because you're now in the context of plugin's repo,
Workflow dispatch solves this. Please provide an example if I'm not understanding.
We can enable workflow write permissions on our app. There's no issue with that.
I think partners would prefer the bot have minimal permissions.
Workflow dispatch solves this. Please provide an example if I'm not understanding.
Workflow dispatch is for invoking the plugin, but when the plugin finishes and wants to send the result back via repository dispatch, it can't act on the behalf of the Github app but rather in the scope of the plugin repo.
Example:
# Comment event received without a recognized user command.
@@ No latest assign event found. @@
Now that we have a prototype of delegated compute[^1] to move towards a paid API infrastructure we should make a dedicated endpoint that has secure access control.
Definitions
Partners
- this is where the work is being done.Permits
- this is our paid endpoint, which is being prototyped on GitHub Actions now.Version I
A specialized version of the API that will be used specifically for our current use-case, which is calculating comment incentives, and assignee rewards.
Permits
InputThis may be simpler to implement, as it will be specifically for the comment incentives.
Permits
will fetch the repository comments from the GitHub API using thegitHubPersonalAccessToken
.Permits
OutputWe can just send the entire comment body with the permits as HTML.
Fee Collection
[^1]: essentially delegating a serverless function to another async runtime that supports longer running operations, and then returning results via a webhook
Version II
Permits
InputWe can generalize this API for any GitHub event, and any GitHub repository. This would allow us to have a single endpoint for all of our partners, and we can use the
eventName
to determine therewards
structure.Permits
Output