binary

type ExecuteRequest ¶

type ExecuteRequest struct {
	// PluginName is the name of the plugin whose binary will be used.
	// If empty, the active plugin binary will be used.
	PluginName string

	// Args are the arguments to pass to the binary.
	Args []string

	// WorkDir is the working directory for execution.
	// If empty, uses the current working directory.
	WorkDir string

	// Interactive indicates whether to run in interactive mode (with TTY).
	Interactive bool
}

ExecuteRequest contains the parameters for executing a binary passthrough.

type ExecuteResponse ¶

type ExecuteResponse struct {
	// ExitCode is the exit code returned by the binary.
	ExitCode int

	// PluginName is the name of the plugin that was executed.
	PluginName string

	// BinaryPath is the path to the binary that was executed.
	BinaryPath string
}

ExecuteResponse contains the result of a binary passthrough execution.

type ImportCustomBinaryUseCase ¶

type ImportCustomBinaryUseCase struct {
	// contains filtered or unexported fields
}

ImportCustomBinaryUseCase orchestrates the import of a custom-built binary into the cache system. It coordinates between version detection, cache storage, and symlink management to:

1. Detect version information from the custom binary
2. Generate cache metadata based on detected version and build config
3. Store the binary in the cache with proper permissions
4. Activate the binary by creating a "current" symlink

This use case follows Clean Architecture principles:

• Depends only on abstractions (ports interfaces)
• Contains core business logic for binary import
• Independent of infrastructure details (OS, filesystem, execution)

SOLID Compliance:

• SRP: Single responsibility of importing custom binaries
• OCP: Extensible via dependency injection without modification
• LSP: Can be used wherever a binary import interface is expected
• ISP: Depends only on necessary interfaces (detector, cache)
• DIP: Depends on abstractions (BinaryVersionDetector, BinaryCache)

func NewImportCustomBinaryUseCase(
	versionDetector ports.BinaryVersionDetector,
	binaryCache ports.BinaryCache,
	homeDir string,
	binaryName string,
) *ImportCustomBinaryUseCase

func (u *ImportCustomBinaryUseCase) Execute(
	ctx context.Context,
	input *dto.CustomBinaryImportInput,
) (*dto.CustomBinaryImportResult, error)

type PassthroughUseCase ¶

type PassthroughUseCase struct {
	// contains filtered or unexported fields
}

PassthroughUseCase orchestrates the binary passthrough flow. It coordinates between BinaryResolver and BinaryExecutor to:

1. Resolve the plugin name to a binary path
2. Execute the binary with provided arguments
3. Handle errors and return exit codes

This use case follows Clean Architecture principles:

• Depends only on abstractions (ports interfaces)
• Contains core business logic
• Independent of infrastructure details

SOLID Compliance:

• SRP: Single responsibility of orchestrating binary passthrough
• DIP: Depends on abstractions (BinaryResolver, BinaryExecutor)
• OCP: Can be extended without modification (e.g., add logging, metrics)

func NewPassthroughUseCase(
	resolver ports.BinaryResolver,
	executor ports.BinaryExecutor,
) *PassthroughUseCase

func (uc *PassthroughUseCase) Execute(ctx context.Context, req ExecuteRequest) (*ExecuteResponse, error)

func (uc *PassthroughUseCase) GetBinaryName(ctx context.Context, pluginName string) (string, error)

func (uc *PassthroughUseCase) ListAvailablePlugins(ctx context.Context) ([]string, error)