Template init

[Keyrxng]

Resolves https://github.com/ubiquibot/plugins-wishlist/issues/13

• based off of ubiquity/ts-template
• action and worker entry points
• common Supabase helpers
• common types

[Keyrxng]

A few questions that I'm unsure of myself.

• So private org config is no longer the approach for secrets and it should all be repo secret based, and that private org config will now be public?
• UBIQUIBOT_TOKEN replaces all instances of GITHUB_TOKEN?
• I remember seeing a comment, but can't find it now, but a worker plugin defines the URL in the config file and the kernel fires it directly to the URL?
• Is returning data to kernel at the end of the plugin still a requirement from both the action and I guess now the worker too?
• context.logger should this be using @ubiquity/logger?
• @ubiquity/configuration isn't needed because all of the validation is done kernel side, the types are kernel focused and defaults are no longer going to be passed from the kernel generateConfig() but from the plugin config instead?

[Keyrxng]

I always forget to tag, @gentlementlegen

[gentlementlegen]

1. There will be an org and a repo based config, and secrets can be passed through it, but for secrets only specific for one repo we will prefer having them directly in that repo. This is mostly to accommodate third party plugins where we don't want to pass down secrets. Only the GitHub app secret is passed around (public or private doesn't really matter).
2. This will be removed, for now at least before we implemented it in a better way. We will use the token in the payload.
3. Correct
4. It is not a requirement yet. The data is not yet processed.
5. context.logged should ideally use the Ubiquity Logger, but currently the logger is too tied to the current implementation and is not usable as such https://github.com/ubiquity/ubiquibot-logger/issues/2
6. Correct. Plugins should also provide an example in the README for a quick setup.

[Keyrxng]

Do you have any more info to add to the readme or would like something added/removed?

A good understanding of how the kernel works and how to interact with it. A basic understanding of the Ubiquibot configuration file and how to define your plugin's settings.

Me in my glass house throwing rocks here with these two comments in the readme when I just barely know what's going on 😂

[gentlementlegen]

The most important information to find there is:

• a valid default configuration to be used within .ubiquibot-configuration.yml
• how to test with Actions
• how to test with Wrangler

For Actions, Nektos Act is nice for local testing. For wrangler, I usually have an http file, like here. See also https://github.com/ubiquibot/assistive-pricing?tab=readme-ov-file#make-requests

Maybe the Kernel should also be mentioned to do a full setup.

[Keyrxng]

@gentlementlegen requested changes made. I also removed the ref to ubqbot_token in Context.ts

[Keyrxng]

Also, would be really appreciated if you could have a look at https://github.com/ubiquity/ubiquibot-logger/issues/2 because it is becoming redundant to every plugin. While it's nice to have it inside of this template, it would be definitely better to have a package that can be shared.

I agree and np if it's still open I'll look into it next week