Refactor hooks api, plugins instantiation #9
Conversation
|
This pull request is automatically deployed with Now. Latest deployment for this branch: https://autobot-git-refactor-plugins.auto-it.now.sh |
| * Gives plugins an opportunity to do whatever it may need to do when PR processing | ||
| * is skipped. This is called _after_ the skip status has been set. | ||
| */ | ||
| onSkip: AsyncParallelHook<[PRContext, Config]>; |
There was a problem hiding this comment.
I found that this whole setup was unnecessary and was just created more issues than it was worth. Giving any random plugin the ability to pump the breaks on the whole process was a little... short sighted.
|
|
||
| interface PluginCollection { | ||
| [pluginName: string]: UninitializedPlugin | InitializedPlugin; | ||
| } |
There was a problem hiding this comment.
Because PR plugins are instantiated in every PR I had issues where statuses were being send multiple times in dev because it's in server, not a lambda. I've essentially made sure that autobot will only ever have 1 instance of a Plugin at any given time.
| @@ -111,16 +113,41 @@ export class Autobot { | |||
|
|
|||
| private initializePlugins(scope: ExecutionScope, context?: PRContext) { | |||
| const scopePluginInstances = <T extends Plugin>() => | |||
| this.plugins.filter(plugin => plugin.scope === scope).map(Plugin => new Plugin()) as T[]; | |||
| Object.values(this.plugins) | |||
| .filter((options): options is UninitializedPlugin => !options.initialized) | |||
|
|
||
| const logger = getLogger("autobot"); | ||
| const STATUS_CONTEXT = isProduction ? "auto-bot" : "auto-bot-dev"; |
There was a problem hiding this comment.
This is so that people can test the dev version without it conflicting with the prod one. Basically can have two autobot apps installed at the same time. (Not that I recommend that of course)
| if (this.failed) { | ||
| logger.info(`${formattedRepoName(context)} PR #${context.payload.number} missing required version labels`, { | ||
| url: context.url, | ||
| }); | ||
| return { | ||
| state: "failure", | ||
| description: "Missing version or skip-release labels", | ||
| state: "pending", |
There was a problem hiding this comment.
I feel like pending is a better representation of the state of the pull request at the point when labels need to be added.
Failed makes it feel like something was done wrong and a change to code is needed. Pending just feels like it's waiting for something (like labels in this case).
What do you think @hipstersmoothie?
No description provided.