Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDK improvements #138

Open
gentlementlegen opened this issue Oct 11, 2024 · 2 comments
Open

SDK improvements #138

gentlementlegen opened this issue Oct 11, 2024 · 2 comments

Comments

@gentlementlegen
Copy link
Member

gentlementlegen commented Oct 11, 2024

The SDK could get some improvements to make it more friendly to use

  • "hono" doesn't seem to be shipped with it but is required to serve the plugin, so it might be included, or even better, encapsulated within the SDK.
  • there is createPlugin and createActionPlugin. Maybe we could have only createPlugin, that would change behavior depending on either the runtime or the environment (e.g. running on a Worker / Action). What would be great that the user doesn't have to worry about this, and locally a GitHub plugin would run as a server, this way it would be easy to debug locally.
  • the Manifest type is not exported. The main issue is that when a JSON is imported directly through import, the type of ubiquity:listeners is a string[] and is incompatible with Manifest.
  • now both Actions and Workers come with a manifest, and this doesn't seem to be currently available for createActionPlugin (might be solved if we merge both function).
  • the validate and decode + inputs could be handled in the SDK (currently just Decodes with no error nor Default).
  • expose the postComment methos to make sure we have metadata on the comments
  • remove duplicated declaration of postComment
  • improve logs for error (there is none at the moment)
  • add GraphQL paginate to Octokit
  • option to disable the signature check for ease of use locally
@whilefoo
Copy link
Contributor

  • "hono" doesn't seem to be shipped with it but is required to serve the plugin, so it might be included, or even better, encapsulated within the SDK.

It is shipped with the SDK?

  • there is createPlugin and createActionPlugin. Maybe we could have only createPlugin, that would change behavior depending on either the runtime or the environment (e.g. running on a Worker / Action). What would be great that the user doesn't have to worry about this, and locally a GitHub plugin would run as a server, this way it would be easy to debug locally.

I guess we could check if the code is running in Github Actions by the env GITHUB_ACTIONS that is set by Github. However if it's a Worker plugin you need to export the Hono app while the Action plugin runs the code immediately so I'm not sure how to deal with that.
Also the Worker plugin requires Manifest to be provided to serve it through Hono while Action plugins don't need that

  • now both Actions and Workers come with a manifest, and this doesn't seem to be currently available for createActionPlugin (might be solved if we merge both function).

The Action plugin doesn't serve the manifest though, the kernel gets it through GIthub API

  • the validate and decode + inputs could be handled in the SDK (currently just Decodes with no error nor Default).

Decode validates and decodes, I added Default in the PR

@gentlementlegen
Copy link
Member Author

@whilefoo I might have been confused with the /node-server when I tried to run it locally, I will test again.

I guess we could check if the code is running in Github Actions by the env GITHUB_ACTIONS that is set by Github

yes that might work I'll have a look at it if I have some time.

The Action plugin doesn't serve the manifest though, the kernel gets it through GIthub API

Good point, maybe it would be more interesting to pass the manifest within Options instead of the arguments to unify both functions.

Decode validates and decodes, I added Default in the PR

Thanks!

Also I seem to run into trouble when I try to start Action plugins with the signature. I am using the same kernel for an Action and a Worker, the Worker signature works fine whereas the Action throws an invalid signature all the time. Am I doing something wrong?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants