mattermost/plugin/supervisor.go

// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved.
// See License.txt for license information.

package plugin

// Supervisor provides the interface for an object that controls the execution of a plugin. This
// type is only relevant to the server, and isn't used by the plugins themselves.
type Supervisor interface {
	Start(API) error
	Wait() error
	Stop() error
	Hooks() Hooks
}
add missing license headers, test to makefile (#7711) 2017-10-25 11:33:19 -05:00			`// Copyright (c) 2015-present Mattermost, Inc. All Rights Reserved.`
			`// See License.txt for license information.`

PLT-7407: Back-end plugin mechanism (#7177) * begin backend plugin wip * flesh out rpcplugin. everything done except for minor supervisor stubs * done with basic plugin infrastructure * simplify tests * remove unused test lines 2017-08-16 17:23:38 -05:00			`package plugin`

more plugin doc updates (#7767) 2017-11-03 11:34:44 -05:00			`// Supervisor provides the interface for an object that controls the execution of a plugin. This`
			`// type is only relevant to the server, and isn't used by the plugins themselves.`
PLT-7407: Back-end plugin mechanism (#7177) * begin backend plugin wip * flesh out rpcplugin. everything done except for minor supervisor stubs * done with basic plugin infrastructure * simplify tests * remove unused test lines 2017-08-16 17:23:38 -05:00			`type Supervisor interface {`
call OnActivate after plugin crash, update example (#7940) 2017-12-05 08:19:32 -06:00			`Start(API) error`
MM-8622: Improved plugin error reporting (#8737) * allow `Wait()`ing on the supervisor In the event the plugin supervisor shuts down a plugin for crashing too many times, the new `Wait()` interface allows the `ActivatePlugin` to accept a callback function to trigger when `supervisor.Wait()` returns. If the supervisor shuts down normally, this callback is invoked with a nil error, otherwise any error reported by the supervisor is passed along. * improve plugin activation/deactivation logic Avoid triggering activation of previously failed-to-start plugins just becase something in the configuration changed. Now, intelligently compare the global enable bit as well as the each individual plugin's enabled bit. * expose store to manipulate PluginStatuses * expose API to fetch plugin statuses * keep track of whether or not plugin sandboxing is supported * transition plugin statuses * restore error on plugin activation if already active * don't initialize test plugins until successfully loaded * emit websocket events when plugin statuses change * skip pruning if already initialized * MM-8622: maintain plugin statuses in memory Switch away from persisting plugin statuses to the database, and maintain in memory instead. This will be followed by a cluster interface to query the in-memory status of plugin statuses from all cluster nodes. At the same time, rename `cluster_discovery_id` on the `PluginStatus` model object to `cluster_id`. * MM-8622: aggregate plugin statuses across cluster * fetch cluster plugin statuses when emitting websocket notification * address unit test fixes after rebasing * relax (poor) racey unit test re: supervisor.Wait() * make store-mocks 2018-05-23 14:26:35 -04:00			`Wait() error`
PLT-7407: Back-end plugin mechanism (#7177) * begin backend plugin wip * flesh out rpcplugin. everything done except for minor supervisor stubs * done with basic plugin infrastructure * simplify tests * remove unused test lines 2017-08-16 17:23:38 -05:00			`Stop() error`
			`Hooks() Hooks`
			`}`