Skip to content
New issue

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

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

Already on GitHub? # to your account

Plugins #42

Merged
merged 25 commits into from
Jun 1, 2024
Merged

Plugins #42

merged 25 commits into from
Jun 1, 2024

Conversation

JackBister
Copy link
Owner

No description provided.

JackBister and others added 25 commits October 3, 2023 19:48
The idea:
* Move public interfaces to pkg/logsuck. There shouldn't be much code
here, just structs and interfaces. Packages in this folder must not
use internal packages. Packages in this folder are used by plugins.

* Put plugins in the plugins directory. Plugins should not use any
internal packages. Plugins implement interfaces and provide them into
the dependency injection context on startup.

* Internal packages can reference pkg/logsuck freely. Internal packages
should not reference plugins. The only exceptions are the
DependencyInjection.go file and tests which may use plugins for
convenience.

Plugins are currently not loadable dynamically. Instead, if you want to
use a plugin you must update the DependencyInjection.go file and build.
This seems like an acceptable tradeoff for now since there are some
caveats with using the Go plugin system.
Having Gin log in its default format was causing issues when trying to parse Logsuck's own logs
This allows plugins and tasks to provide schemas for their configuration
, making it much easier to configure them through the GUI.

A downside of this is that SQLite configuration is moved to the
"plugins" key in the config. Since SQLite is supposed to be a part of
the base Logsuck build this is a bit ugly. Maybe SQLite should be
special cased to also be included in the base configuration.
Avoids stuttering like "pipeline.PipelinePipe" and settles on prefixing
implementations of interfaces (i.e. SqliteConfigRepository instead of
ConfigRepositorySqlite)
Core plugins are treated specially when it comes to the config schema.
Instead of being stored under the plugins key in the schema, core
plugins can put their configuration in the root of the config object.
This keeps compatibility with Logsuck configs created before plugins
were added and looks much cleaner in the schema.
This lays the groundwork for making it possible to read events from
other sources through plugins.
@JackBister JackBister merged commit 835d429 into master Jun 1, 2024
1 check passed
@JackBister JackBister deleted the plugins branch June 1, 2024 18:44
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant