Plugin System

Relevant source files

The following files were used as context for generating this wiki page:

• iac-recert-engine/internal/plugin/plugin.go
• iac-recert-engine/internal/config/types.go
• iac-recert-engine/example.config.yaml
• iac-recert-engine/internal/engine/engine.go
• iac-recert-engine/internal/assign/resolver.go
• iac-recert-engine/internal/config/types_test.go

The iac-recert-engine includes a plugin system designed to extend its core functionality. This system allows for custom logic to be integrated into various stages of the recertification process, primarily for determining pull request assignments and potentially for filtering files. The architecture is centered around a PluginManager that loads and provides access to configured plugins.

While the framework for plugins is established, the current implementation serves as a placeholder. The system identifies plugin configurations but does not dynamically load external code. Instead, it provides the interfaces and integration points for future expansion, such as supporting built-in plugins registered by name.

Sources: internal/plugin/plugin.go:30-34, internal/config/types.go:68-74

Architecture

The plugin architecture consists of a central manager, defined interfaces for different plugin types, and a configuration structure.

Sources: internal/plugin/plugin.go, internal/config/types.go

Plugin Manager

The Manager is the core component responsible for handling the lifecycle of plugins. It is initialized by the main Engine with the plugin configurations from the config.yaml file.

• Manager struct: Holds a map of all loaded plugin instances, keyed by their configuration name.
• NewManager function: The constructor for the Manager. It iterates through the PluginConfigs from the main configuration, and for each enabled plugin, it logs its intent to load it. The actual logic for loading external or built-in plugins is marked as a TODO.
• GetAssignmentPlugin function: A type-safe getter to retrieve a loaded plugin that implements the AssignmentPlugin interface.

This diagram shows the initialization flow of the Plugin Manager within the application.

Plugin Interfaces and Types

The system defines a set of interfaces that plugins must implement to be compatible with the engine.

Interface/Type	Description	File
PluginType	A string constant defining the type of a plugin. Currently supports assignment and filter.	internal/plugin/plugin.go:11-14
Plugin	The base interface for all plugins. It requires an Init method for setup, which receives the plugin-specific configuration map.	internal/plugin/plugin.go:16-18
AssignmentPlugin	An interface for plugins that determine assignees for a pull request. It embeds the base Plugin interface and adds a Resolve method.	internal/plugin/plugin.go:20-23

The Resolve method takes a slice of types.FileInfo and is expected to return an AssignmentResult, which contains the resolved assignees and reviewers.

Sources: internal/plugin/plugin.go:11-23, internal/types/types.go:29-34

Configuration

Plugins are defined in the main configuration file under the plugins key. This section is a map where each key is a unique name for a plugin configuration.

Sources: example.config.yaml:70-76, internal/config/types.go:68-74

Example Configuration

# Plugin Configuration (Optional)
plugins:
  cmdb_assignment:
    enabled: false
    type: "assignment"
    module: "cmdb"
    config:
      api_url: "https://cmdb.example.com"

Sources: example.config.yaml:70-76

Configuration Fields

The PluginConfig struct defines the structure for each plugin entry.

Field	Type	Description	Required
enabled	bool	If true, the plugin will be loaded by the manager.	No
type	string	The type of the plugin (e.g., assignment).	Yes
module	string	The name or path of the module to be loaded.	Yes
config	map[string]string	A key-value map of custom configuration options passed to the plugin's Init method.	No

Sources: internal/config/types.go:70-75

Integration with Core Engine

The plugin system is integrated into other parts of the engine, allowing strategies for PR grouping and assignment to be delegated to a plugin.

Assignment Strategy

The assignment.strategy can be set to plugin. The assignment.Resolver is responsible for executing this logic.

• The Resolver is initialized with the plugin.Manager.
• When Resolve is called and the strategy is plugin, it is intended to retrieve the appropriate AssignmentPlugin from the manager and call its Resolve method.
• The current implementation notes that this logic is not yet fully implemented.

This sequence diagram illustrates the intended flow for an assignment plugin.

PR Grouping Strategy

The pr_strategy.type can also be set to plugin. This would allow a plugin to define how files needing recertification are grouped into pull requests. The configuration includes a plugin_name field to specify which plugin to use for this purpose.

Sources: internal/config/types.go:53-56