feat: configuration annotations #112
Conversation
For Actions, it triggers a |
|
@whilefoo Please let me know if the logic makes sense, I'll be working on the changes required in the plugins if you give it your go. |
|
Looks good, just wondering if it would be better for plugin to provide the schema for the |
|
@whilefoo I thought about it but the dangerous thing is that it would allow for possible code injection, and also in the case of plugins like |
Changes
|
|
Will the Github action which updates the configuration in the manifest work both for worker and action plugins? I thought worker plugins will have a separate endpoint to provide the json schema but I guess it makes more sense to put in the manifest to make it uniform for both types of plugins |
|
@whilefoo my idea is that I will add an Action script running on |
| if (context.payload.action === "configuration_validation") { | ||
| return handleActionValidationWorkflowCompleted(context); | ||
| } else if (context.payload.action !== "return_data_to_ubiquibot_kernel") { | ||
| if (context.payload.action !== "return_data_to_ubiquibot_kernel") { |
There was a problem hiding this comment.
Let's deprecate ubiquibot in favor of ubiquity-os
Resolves #80
QA: https://github.com/Meniole/ubiquibot-config/commit/7aaa773aaf3eb93ea1bf1e15706bdc20d2c3e988#commitcomment-147051448
Changes
The kernel is now capable to check the validity of a given configuration. On
pushevent, if the commits contain the.github/.ubiquibot-config.yml, the kernel will proceed to verify its content. It does the current checks:withsends the proper argumentsIf any of these checks fail, an annotation is made within the commit, pointing to the faulty line.
Side tasks
validate-workflow.yml/manifestendpoint