executor

package
v0.1.0 Latest Latest
Warning

This package is not in the latest version of its module.

Go to latest
Published: Aug 30, 2026 License: MIT Imports: 18 Imported by: 0

Documentation

Overview

Package executor runs a provider-agnostic pipeline.Pipeline by creating a Docker container per job and executing its steps inside it via the Docker Engine API (never by shelling out to the docker CLI).

Index

Constants

This section is empty.

Variables

View Source
var ErrAborted = fmt.Errorf("pipeline aborted by user")

ErrAborted is returned by Run/runJob when a StepController returns Abort for a step that had itself succeeded (an unprompted failure instead surfaces its own, more specific error).

Functions

This section is empty.

Types

type Decision

type Decision int

Decision is the debugger's answer to whether the pipeline should keep going after a step, returned from StepController.AfterStep.

const (
	// Continue moves on to the pipeline's next step, even one that
	// followed a failed step — a debugger may let the user override a
	// failure and keep going to investigate further.
	Continue Decision = iota
	// Abort stops the whole pipeline immediately.
	Abort
)

type Docker

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

Docker executes pipelines against a Docker Engine.

func New

func New(log Logger, opts ...Option) (*Docker, error)

New connects to the local Docker Engine and returns a Docker executor. If DOCKER_HOST is unset, it resolves the host from the Docker CLI's active context (as `docker` itself does), so engines like Colima or Rancher Desktop that aren't the "default" context are found without the caller having to export DOCKER_HOST by hand.

func (*Docker) Close

func (d *Docker) Close() error

Close releases the underlying Docker client connection.

func (*Docker) Run

func (d *Docker) Run(ctx context.Context, p *pipeline.Pipeline) error

Run executes every stage of the pipeline in order; within a stage, jobs run sequentially in the order they were defined. Execution stops at the first failing job.

func (*Docker) Shell

func (d *Docker) Shell(ctx context.Context, containerID string) error

Shell drops the caller into an interactive shell inside the given container, wiring os.Stdin/os.Stdout to it over a Docker exec TTY. It prefers bash if the image has it, falling back to sh, and blocks until the shell exits.

type Logger

type Logger interface {
	// JobStart is called before a job's first step runs.
	JobStart(jobName, stage, image string)
	// StepStart is called before a step runs.
	StepStart(jobName, stepName, command string)
	// StepOutput is called with a chunk of a step's combined stdout/stderr.
	StepOutput(jobName, stepName string, chunk []byte)
	// StepDone is called after a step finishes.
	StepDone(jobName, stepName string, exitCode int64, err error)
	// JobDone is called after a job's steps finish (or one failed).
	JobDone(jobName string, err error)
}

Logger receives streamed pipeline output. Both methods are called synchronously from the goroutine running the pipeline.

type Option

type Option func(*Docker)

Option configures optional behavior on a Docker executor.

func WithController

func WithController(c StepController) Option

WithController attaches a debugger layer that is asked, after every step, whether the pipeline should continue or abort.

func WithWorkspace

func WithWorkspace(hostPath string) Option

WithWorkspace overrides the host directory bind-mounted into every job's container at /workspace (read-write). Defaults to the current working directory, matching how a real checkout puts the repo at the job's working directory.

type ShellFunc

type ShellFunc func(ctx context.Context) error

ShellFunc drops the caller into an interactive shell inside the container a step just ran in, wiring the real terminal's stdin/stdout to it. It blocks until the user exits the shell.

type StepController

type StepController interface {
	AfterStep(ctx context.Context, jobName string, step pipeline.Step, exitCode int64, stepErr error, shell ShellFunc) Decision
}

StepController is consulted after every step finishes, letting a debugger layer pause the pipeline, offer an interactive shell in the step's own container, and decide whether to continue or abort. When nil, the executor runs straight through and stops automatically at the first failing step (Phase 1 behavior).

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL