lath cli

A task runner where tasks are typed Go functions and a deploy runs the same on a laptop, over ssh and in CI.

go install github.com/ubgo/lath/cmd/lath@latest

Language: Go
Go version: –
Core deps: –
Latest tag: 4 streams
License: Apache-2.0
Go modules: 6

How it fits together

Code from the README

func Name()
func Name() error
func Name(ctx context.Context) error
func Name(args ...string) error
func Name(ctx context.Context, args ...string) error

pipeline.Func{
    Label:      "record-deploy",
    Needs:      []pipeline.Key{common.KeyImage},
    Idempotent: true, // safe to replay under `lath tui`
    Do: func(ctx context.Context, s *pipeline.State) error {
        image, err := pipeline.Get[string](s, common.KeyImage)
        if err != nil { return err }
        s.Detailf("appended %s to the deploy log", image)
        return nil
    },
}

From the lath README.

At a glance (from the README)

Module	Depends on	Why it is separate
`github.com/ubgo/lath/pipeline`	nothing of ours	the engine is domain-free: no Docker, no SSH, no notion of a deploy. Reusable for any staged process.
`github.com/ubgo/lath/steps`	`github.com/ubgo/lath/pipeline`	the deploy primitives. A project can swap these wholesale without touching execution semantics.
`github.com/ubgo/lath/cmd/lath`	`kit`, `pipeline`, for the debugger only	the runner compiles a definition; it never imports one, and links no deploy library. The two exceptions are the step debugger’s transport, which both ends must agree on.
`deploydef`	`pipeline`, `steps`, never the runner	the definition. A nested module outside `go.work`, so its dependencies never enter the application’s module graph.