structcli

2024-02-12T00:00:00+00:00

Declare your CLI contract once in Go structs. structcli</code> turns it into flags, env vars, config-file loading, validation, organized help, and machine-readable contracts for agents.

Less Cobra/Viper boilerplate</li> Better CLIs for humans</li> Better contracts for automation and LLMs</li>

Compiles to WASM out of the box</li> </ul> Stop writing plumbing. Start shipping commands. ⚡ Quick Start§</a> </h2> Start with a plain Go struct: package main import ( "fmt" "github.com/leodido/structcli" "github.com/spf13/cobra" "go.uber.org/zap/zapcore" ) type Options struct { LogLevel zapcore.Level Port int } func main() { opts := &Options{} cli := &cobra.Command{ Use: "myapp", RunE: func(c *cobra.Command, args []string) error { fmt.Println(opts) // already populated return nil }, } structcli.Bind(cli, opts) structcli.ExecuteOrExit(cli) }</code></pre> Bind</code> creates flags and env vars from your struct and registers it for auto-unmarshal. ExecuteOrExit</code> hydrates the struct from flags, env vars, config, and defaults before your RunE</code> fires. ❯ go run examples/minimal/main.go --help # Usage: # myapp [flags] # # Flags: # -h, --help help for myapp # --loglevel zapcore.Level {debug,info,warn,error,dpanic,panic,fatal} (default info) # --port int</code></pre> Add tags when you want aliases, env vars, shorthand, defaults, and descriptions: type Options struct { LogLevel zapcore.Level `flag:"level" flagdescr:"Set logging level" flagenv:"true"` Port int `flagshort:"p" flagdescr:"Server port" flagenv:"true" default:"3000"` }</code></pre>❯ go run examples/simple/main.go -h # A simple CLI example # # Usage: # myapp [flags] # # Flags: # -h, --help help for myapp # --level zapcore.Level Set logging level {debug,info,warn,error,dpanic,panic,fatal} (default info) # -p, --port int Server port (default 3000) # # Global Flags: # --jsonschema string[="true"] output JSON Schema and exit (bare: this command, =tree: full subtree) # --mcp serve MCP over stdio</code></pre>❯ MYAPP_LOGLEVEL=debug go run examples/simple/main.go # &{debug 3000}</code></pre>❯ MYAPP_LOGLEVEL=error MYAPP_PORT=9000 go run examples/simple/main.go --level dpanic # &{dpanic 9000}</code></pre> Built-in types like zapcore.Level</code> are validated automatically too. Out of the box, your CLI supports: 📝 Command-line flags (--level info</code>, -p 8080</code>)</li> 🌍 Environment variables (MYAPP_PORT=8080</code>)</li> 💦 Options precedence (flags > env vars > config file > defaults)</li> ✅ Automatic validation and type conversion</li> 📚 Beautiful help output with proper grouping</li> </ul> Add the AI-native wiring below and it also gains machine-readable JSON Schema, structured JSON errors, semantic exit codes, and optional MCP tool-server mode for agents. Build AI-Native CLIs§</a> </h2> structcli</code> does not just generate flags for humans. It can make your CLI legible to agents too. Instead of scraping --help</code> and guessing, an agent can discover the contract, call the command correctly, and recover from structured failures. structcli.Setup(rootCmd, structcli.WithJSONSchema(), structcli.WithHelpTopics(helptopics.Options{ReferenceSection: true}), // "mycli env-vars" and "mycli config-keys" structcli.WithFlagErrors(), // Optional, but recommended for typed flag-parse errors structcli.WithMCP(), // Optional, exposes the CLI as an MCP server over stdio ) structcli.ExecuteOrExit(rootCmd)</code></pre> With that wiring: --jsonschema</code> exposes flags, defaults, required inputs, enums, and env bindings for the current command; --jsonschema=tree</code> dumps the entire subtree in one call</li> mycli env-vars</code> and mycli config-keys</code> list every environment variable binding and config file key across the command tree</li> HandleError</code> / ExecuteOrExit</code> emit structured JSON errors instead of forcing callers to parse human-oriented output</li> --mcp</code> exposes the same command tree as MCP tools over stdio, with typed inputs and structured tool-call failures</li> semantic exit codes tell the caller whether it should fix input, fix config, retry, or escalate to a human</li> </ul> The same contract spans flags, env vars, config, validation, and enum constraints. $ mycli srv --jsonschema { "properties": { "port": { "type": "integer", "default": 3000, "x-structcli-env-vars": ["MYCLI_SRV_PORT"] }, "secret-key": { "type": "string", "x-structcli-env-vars": ["MYCLI_SRV_SECRET_KEY"], "x-structcli-env-only": true } }, "x-structcli-config-flag": "config" }</code></pre> Use --jsonschema=tree</code> to dump the entire command subtree in a single call: no need to invoke each subcommand separately: $ mycli --jsonschema=tree # JSON array of schemas for all commands $ mycli srv --jsonschema=tree # schemas for srv + its subcommands</code></pre> No --help</code> parsing. No guessing what failed. Just a CLI that can explain itself and fail in machine-actionable ways. Use exitcode.Category(code)</code> and exitcode.IsRetryable(code)</code> to decide what to do next. See jsonschema.WithEnumInDescription()</code> for schema customization, and pass schema options through WithJSONSchema</code> with jsonschema.Options{SchemaOpts: ...}</code>. For CLIs that capture output streams during command construction, configure mcp.Options.CommandFactory</code> so each MCP tool call builds a fresh command with the tool-call stdout and stderr writers. This keeps MCP protocol output separate from command output while preserving the existing command tree schema. If the command constructor requires stdin, the factory can wire a non-interactive reader such as strings.NewReader("")</code>. For build-time discovery, generate.WriteAll</code> produces SKILL.md, llms.txt, and AGENTS.md from the same struct definitions: wire it into //go:generate</code> and the files stay in sync automatically. Read the full AI-native guide</a> or walk through the runnable structured error example</a>. ⬇️ Install§</a> </h2> go get github.com/leodido/structcli</code></pre>📦 Key Features§</a> </h2> 🧩 Declarative Flags Definition§</a> </h3> Define flags once using Go struct tags. No more boilerplate for Flags().StringVarP</code>, Flags().IntVar</code>, viper.BindPFlag</code>, etc. Yes, you can nest structs too. type ServerOptions struct { // Basic flags Host string `flag:"host" flagdescr:"Server host" default:"localhost"` Port int `flagshort:"p" flagdescr:"Server port" flagrequired:"true" flagenv:"true"` // Environment variable binding APIKey string `flagenv:"true" flagdescr:"API authentication key"` // Network contracts using net families BindIP net.IP `flag:"bind-ip" flaggroup:"Network" flagdescr:"Bind interface IP" flagenv:"true"` BindMask net.IPMask `flag:"bind-mask" flaggroup:"Network" flagdescr:"Bind interface mask" flagenv:"true"` AdvertiseCIDR net.IPNet `flag:"advertise-cidr" flaggroup:"Network" flagdescr:"Advertised service subnet (CIDR)" flagenv:"true"` TrustedPeers []net.IP `flag:"trusted-peers" flaggroup:"Network" flagdescr:"Trusted peer IPs (comma separated)" flagenv:"true"` // Flag grouping for organized help LogLevel zapcore.Level `flag:"log-level" flaggroup:"Logging" flagdescr:"Set log level"` LogFile string `flag:"log-file" flaggroup:"Logging" flagdescr:"Log file path" flagenv:"true"` // Nested structs for organization Database DatabaseConfig `flaggroup:"Database"` // Enum type (registered via RegisterEnum) TargetEnv Environment `flag:"target-env" flagdescr:"Set the target environment" default:"dev"` } type DatabaseConfig struct { URL string `flag:"db-url" flagdescr:"Database connection URL"` MaxConns int `flagdescr:"Max database connections" default:"10" flagenv:"true"` }</code></pre> See full example</a> for more details. 🛠️ Automatic Environment Variable Binding§</a> </h3> Automatically generate environment variables binding them to configuration files (YAML, JSON, TOML, etc.) and flags. From the previous options struct, you get the following env vars automatically: FULL_SRV_PORT</code></li> FULL_SRV_APIKEY</code></li> FULL_SRV_BIND_IP</code></li> FULL_SRV_BIND_MASK</code></li> FULL_SRV_ADVERTISE_CIDR</code></li> FULL_SRV_TRUSTED_PEERS</code></li> FULL_SRV_DATABASE_MAXCONNS</code></li> FULL_SRV_LOGFILE</code>, FULL_SRV_LOG_FILE</code></li> </ul> Every struct field with the flagenv:"true"</code> tag gets an environment variable (two if the struct field also has the flag:"..."</code> tag, see struct field LogFile</code>). Use flagenv:"only"</code> for fields that should be settable exclusively via environment variable or config file: CLI usage (--flag=value</code>) is rejected at runtime. The prefix of the environment variable name is the CLI name plus the command name to which those options are attached to. Environment variables are command-scoped for command-local options. For example, if Port</code> is attached to the srv</code> command, FULL_SRV_PORT</code> is used (not FULL_PORT</code>). ⚙️ Configuration File Support§</a> </h3> Set up configuration file discovery (flag, environment variable, and fallback paths) via Setup</code>: structcli.Setup(rootCmd, structcli.WithAppName("full"), structcli.WithConfig(config.Options{}), )</code></pre> Enable strict config-key validation with: structcli.Setup(rootCmd, structcli.WithAppName("full"), structcli.WithConfig(config.Options{ValidateKeys: true}), )</code></pre> When enabled, Unmarshal</code> fails if command-relevant config contains unknown keys. WithAppName</code> sets the env prefix. WithConfig</code> registers the --config</code> flag and defers config loading to ExecuteC</code>'s bind pipeline (before auto-unmarshal). Ordering between Setup</code> and Bind</code> does not matter: WithAppName</code> retroactively patches env annotations on already-defined flags. Individual SetupConfig</code>, SetupDebug</code>, etc. remain available for power users who need fine-grained control. The line above: creates --config</code> global flag</li> creates FULL_CONFIG</code> env var</li> sets /etc/full/</code>, $HOME/.full/</code>, $PWD/.full/</code> as fallback paths for config.yaml</code></li> </ul> Magic, isn't it? What's left? Tell your CLI to load the configuration file (if any). rootC.PersistentPreRunE = func(c *cobra.Command, args []string) error { _, configMessage, configErr := structcli.UseConfigSimple(c) if configErr != nil { return configErr } if configMessage != "" { c.Println(configMessage) } return nil }</code></pre> UseConfigSimple(c)</code> loads config into the root config scope and merges only the relevant section into c</code>'s effective scope. 🧠 Viper Model Scopes§</a> </h4> structcli</code> uses two different viper scopes on purpose: structcli.GetConfigViper(rootOrLeafCmd)</code> -> root-scoped config source (config file data tree)</li> structcli.GetViper(cmd)</code> -> command-scoped effective values (flags/env/defaults + command-relevant config)</li> </ul> This separation keeps config-file loading isolated from runtime command state. If you need imperative values in tests or application code, write to the right scope: // 1) Effective override for one command context structcli.GetViper(cmd).Set("timeout", 60) // 2) Config-tree style injection (top-level + command section) structcli.GetConfigViper(rootCmd).Set("srv", map[string]any{ "port": 8443, })</code></pre> Global viper.Set(...)</code> is not used by structcli.Unmarshal(...)</code> resolution. Use GetViper</code>/GetConfigViper</code> instead. 📜 Configuration Is First-Class Citizen§</a> </h4> Configuration can mirror your command hierarchy. Settings can be global (at the top level) or specific to a command or subcommand. The most specific section always takes precedence. # Global settings apply to all commands unless overridden by a specific section. # `dryrun` matches the `DryRun` struct field name. dryrun: true verbose: 1 # A default verbosity level for all commands. # Config for the `srv` command (`full srv`) srv: # `port` matches the `Port` field name. port: 8433 # Network options bind-ip: "10.20.0.10" bind-mask: "ffffff00" advertise-cidr: "10.20.0.0/24" trusted-peers: "10.20.0.11,10.20.0.12" # `log-level` matches the `flag:"log-level"` tag. log-level: "warn" # `logfile` matches the `LogFile` field name. logfile: /var/log/mysrv.log # Flattened keys can set options in nested structs. # `db-url` (from `flag:"db-url"` tag) maps to ServerOptions.Database.URL. db-url: "postgres://user:pass@db/prod" # Nested keys are also supported. database: # Struct field key style url: "postgres://user:pass@db/prod" # Alias key style (from `flag:"db-url"`) db-url: "postgres://user:pass@db/prod" # Config for the `usr` command group. usr: # This nested section matches the `usr add` command (`full usr add`). # Its settings are ONLY applied to 'usr add'. add: name: "Config User" email: "config.user@example.com" age: 42 # Command specific override dry: false # NOTE: Per the library's design, there is no other fallback other than from the top-level. # A command like 'usr delete' would ONLY use the global keys above (if those keys/flags are attached to it), # as an exact 'usr.delete' section is not defined.</code></pre> This configuration system supports: Hierarchical Structure: Nest keys to match your command path (e.g., usr: { add: { ... } }</code>).</li> Strict Precedence: Only settings from the global scope and the exact command path section are merged. There is no automatic fallback to parent command sections.</li> Flexible Keys: You can use struct field names and aliases (flag:"..."</code>) in both flattened and nested forms.</li> Supported Forms for Nested Fields: db-url</code>, database.url</code>, database: { url: ... }</code>, and database: { db-url: ... }</code>.</li> </ul> ✅ Built-in Validation & Transformation§</a> </h3> Supports validation, transformation, and custom flag type definitions through simple interfaces. Your struct must implement Options</code> (via Attach</code>) and can optionally implement ValidatableOptions</code> and TransformableOptions</code>. type UserConfig struct { Email string `flag:"email" flagdescr:"User email" validate:"email"` Age int `flag:"age" flagdescr:"User age" validate:"min=18,max=120"` Name string `flag:"name" flagdescr:"User name" mod:"trim,title"` } func (o *ServerOptions) Validate(ctx context.Context) []error { // Automatic validation } func (o *ServerOptions) Transform(ctx context.Context) error { // Automatic transformation }</code></pre> See a full working example here</a>. 🚧 Automatic Debugging Support§</a> </h3> Create a --debug-options</code> flag (plus a matching env var) for troubleshooting config/env/flags resolution. structcli.Setup(rootCmd, structcli.WithDebug(debug.Options{}))</code></pre> Or standalone: structcli.SetupDebug(rootCmd, debug.Options{})</code>. The flag accepts text</code> (default when used bare) or json</code> for machine-readable output. Truthy values like true</code>, 1</code>, yes</code> are treated as text</code> for backward compatibility. Text output: an aligned table showing each flag's resolved value and where it came from: ❯ go run examples/full/main.go srv --debug-options --config examples/full/config.yaml -p 3333 # ... # Command: full srv # # Flags: # --apikey secret-api-key (default) # --config examples/full/config.yaml (flag) # --database.maxconns 3 (default) # --db-url postgres://user:pass@localhost/mydb (default) # --debug-options text (flag) # --host production-server (default) # --log-file /var/log/mysrv.log (default) # --log-level debug (default) # --port 3333 (flag) # --target-env dev (default) # ... # # Values: # apikey: secret-api-key # host: production-server # log-level: debug # port: 3333 # ...</code></pre> JSON output: structured data for AI agents and tooling: ❯ go run examples/full/main.go srv --debug-options=json --config examples/full/config.yaml -p 3333 # ... # { # "command": "full srv", # "flags": [ # ... # {"name": "config", "value": "examples/full/config.yaml", "default": "", "changed": true, "source": "flag"}, # {"name": "db-url", "value": "postgres://user:pass@localhost/mydb", "default": "", "changed": false, "source": "default"}, # {"name": "log-level", "value": "debug", "default": "info", "changed": false, "source": "default"}, # {"name": "port", "value": "3333", "default": "0", "changed": true, "source": "flag"}, # ... # ], # "values": {"apikey": "secret-api-key", "host": "production-server", "log-level": "debug", "port": 3333, ...} # }</code></pre> Source attribution resolves each flag to flag</code> (CLI), env</code>, config</code>, or default</code>. For env-sourced flags, the text output includes the variable name (e.g., (env: MYAPP_LOG_LEVEL)</code>). The flag can also be activated via environment variable: FULL_DEBUG_OPTIONS=json</code>. 📋 Self-Documenting Help Topics§</a> </h3> WithHelpTopics</code> (or standalone SetupHelpTopics</code>) adds two help topic commands that list every environment variable binding and every valid configuration file key across the command tree. structcli.Setup(rootCmd, structcli.WithHelpTopics(helptopics.Options{}))</code></pre> Call this after all subcommands and flags are defined (typically right before ExecuteOrExit</code>). By default the commands appear as regular subcommands under "Available Commands:". Set ReferenceSection: true</code> to move them into a dedicated "Reference:" section instead. Environment variable listing: mycli env-vars</code>: Environment Variables mycli (global): MYCLI_VERBOSE --verbose bool false mycli serve: MYCLI_SERVE_HOST --host string localhost MYCLI_SERVE_PORT --port int 8080</code></pre> Configuration key listing: mycli config-keys</code>: Configuration Keys Config flag: --config Supported formats: yaml, json, toml. Searches: $HOME/.mycli, /etc/mycli mycli (global): output --output string text verbose --verbose bool false mycli serve: host --host string localhost port --port int 8080 tls-cert --tls-cert string "" Keys can be nested under the command name in the config file.</code></pre> With ReferenceSection: true</code>, both topics appear under "Reference:" in --help</code> output instead of "Available Commands:". Flags marked flagenv:"only"</code> show an (env-only)</code> suffix in the env-vars listing and are excluded from config-keys (since they are hidden). Config keys derived from embedded struct field paths appear as aliases (e.g., database.maxconns</code> → alias for --database.maxconns</code>). For machine-readable cross-tree data, use --jsonschema=tree</code> instead: it provides the same information in structured JSON. ↪️ Sharing Options Between Commands§</a> </h3> In complex CLIs, multiple commands often need access to the same global configuration and shared resources (like a logger or a database connection). structcli</code> provides a pattern using the ContextInjector</code></a> interface to achieve this without resorting to global variables, by propagating a single "source of truth" through the command context. The pattern allows you to: Populate a shared options struct once from flags, environment variables, or a config file.</li> Initialize "computed state" (like a logger) based on those options.</li> Share this single, fully-prepared "source of truth" with any subcommand that needs it.</li> </ul> 🍩 In a Nutshell§</a> </h4> Create a shared struct that implements the ContextInjector</code> interface. This struct will hold both the configuration flags and the computed state (e.g., the logger). // This struct holds our shared state. type CommonOptions struct { LogLevel zapcore.Level `flag:"loglevel" flagdescr:"Logging level" default:"info"` Logger *zap.Logger `flagignore:"true"` // This field is computed, not a flag. } // Context injects the struct into the command context during auto-unmarshal. func (o *CommonOptions) Context(ctx context.Context) context.Context { /* ... */ } // FromContext retrieves the struct from context (user-side, not interface-enforced). func (o *CommonOptions) FromContext(ctx context.Context) error { /* ... */ } // Initialize is a custom method to create the computed state. func (o *CommonOptions) Initialize() error { /* ... */ }</code></pre> Bind the shared struct to the root command. Bind</code> registers it for auto-unmarshal: the bind pipeline populates it and calls Context()</code> to inject it before any PreRunE</code> or RunE</code> fires. structcli.Bind(rootC, commonOpts)</code></pre> Important: Bind</code> on root creates local flags on the root command. By default, Cobra rejects unknown flags before finding the subcommand, so app --loglevel info sub</code> would fail. Set rootC.TraverseChildren = true</code> so root parses its own flags first, then resolves the subcommand. Alternatively, bind the shared struct on each leaf command that needs the flags. </blockquote> If you need to initialize computed state (like a logger) after unmarshal, use a PersistentPreRunE</code> hook: by the time it fires, commonOpts</code> is already populated: rootC.PersistentPreRunE = func(c *cobra.Command, args []string) error { // commonOpts is already populated by the bind pipeline. return commonOpts.Initialize() }</code></pre> Retrieve the state in subcommands. In your subcommand's RunE</code>, call .FromContext()</code> to retrieve the shared, initialized object. func(c *cobra.Command, args []string) error { config := &CommonOptions{} if err := config.FromContext(c.Context()); err != nil { return err } config.Logger.Info("Executing subcommand...") return nil },</code></pre> This pattern ensures that subcommands remain decoupled while having access to a consistent, centrally-managed state. Note: The deprecated ContextOptions</code> interface (which embeds Options</code> and requires Attach</code>) still works for backward compatibility. New code should use ContextInjector</code> instead. </blockquote> For a complete, runnable implementation of this pattern, see the loginsvc example located in the /examples/loginsvc</a> directory. 🎯 Enum Registration§</a> </h3> Register string or integer enum types once in init()</code> and use them as plain struct fields. structcli handles flag creation, help text with allowed values, shell completion, validation, and config/env decoding automatically. String enums (RegisterEnum</code>)§</a> </h4> type Environment string const ( EnvDev Environment = "dev" EnvProd Environment = "prod" ) func init() { structcli.RegisterEnum[Environment](map[Environment][]string{ EnvDev: {"dev", "development"}, // first string is canonical, rest are aliases EnvProd: {"prod", "production"}, }) } type DeployOptions struct { TargetEnv Environment `flag:"target-env" flagdescr:"Target environment" default:"dev" flagenv:"true"` }</code></pre> This produces --target-env</code> with help text showing {dev,prod}</code>, shell completion for all values including aliases, and case-insensitive parsing that accepts both prod</code> and production</code>. Integer enums (RegisterIntEnum</code>)§</a> </h4> type Priority int const ( PriorityLow Priority = 0 PriorityMedium Priority = 1 PriorityHigh Priority = 2 ) func init() { structcli.RegisterIntEnum[Priority](map[Priority][]string{ PriorityLow: {"low"}, PriorityMedium: {"medium", "med"}, PriorityHigh: {"high", "hi"}, }) }</code></pre> Both functions panic on duplicate registration or empty values. Call them in init()</code> before any Define()</code> calls. See full example</a> for enum registration in a complete CLI. 🪃 Custom Type Handlers§</a> </h3> For types that need custom parsing logic beyond what enum registration provides, structcli offers two mechanisms: per-type registration and per-field hooks. Per-type: RegisterType[T]</code>§</a> </h4> Register custom hooks for a type once in init()</code>. Every struct field of type T</code> uses them automatically: no special tags needed. RegisterType</code> panics on nil hooks or duplicate registration: call it in init()</code> before any Define</code>/Bind</code>. import ( "github.com/leodido/structcli" "github.com/leodido/structcli/values" ) type ListenAddress struct { Host string Port int raw string } func init() { structcli.RegisterType[ListenAddress](structcli.TypeHooks[ListenAddress]{ Define: func(name, descr string, sf reflect.StructField, fv reflect.Value) (pflag.Value, string) { ptr := fv.Addr().Interface().(*ListenAddress) *ptr = ListenAddress{Host: "localhost", Port: 8080, raw: "localhost:8080"} return values.NewString(&ptr.raw), descr + " (host:port)" }, Decode: func(input any) (any, error) { return ParseListenAddress(input.(string)) }, }) } type ServerOptions struct { ListenAddr ListenAddress `flag:"listen" flagdescr:"Listen address"` }</code></pre> Both Define</code> and Decode</code> are required. Panics on duplicate registration or nil hooks. Call in init()</code> before any Define</code>/Bind</code> calls. For enum types, prefer RegisterEnum</code>/RegisterIntEnum</code>: they wrap RegisterType</code> with less boilerplate. Per-field: FieldHookProvider</code> and FieldCompleter</code>§</a> </h4> When the same type needs different behavior in different fields, or when a standard type needs custom handling for a specific field, implement FieldHookProvider</code> on your options struct. Map keys are struct field names. type ServerOptions struct { ListenAddr string `flag:"listen" flagdescr:"Listen address"` Mode string `flag:"mode" flagdescr:"Server mode"` } func (o *ServerOptions) FieldHooks() map[string]structcli.FieldHook { return map[string]structcli.FieldHook{ "ListenAddr": { Define: func(name, descr string, sf reflect.StructField, fv reflect.Value) (pflag.Value, string) { ptr := fv.Addr().Interface().(*string) *ptr = "localhost:8080" return values.NewString(ptr), descr + " (host:port)" }, Decode: func(input any) (any, error) { return input, nil }, }, } }</code></pre> For shell completion, implement FieldCompleter</code>: func (o *ServerOptions) CompletionHooks() map[string]structcli.CompleteHookFunc { return map[string]structcli.CompleteHookFunc{ "ListenAddr": func(cmd *cobra.Command, args []string, toComplete string) ([]string, cobra.ShellCompDirective) { return []string{"localhost:8080", "0.0.0.0:8080", "0.0.0.0:443"}, cobra.ShellCompDirectiveNoFileComp }, } }</code></pre> FieldCompleter</code> works for any field that becomes a flag, not only fields with FieldHookProvider</code> hooks. Precedence§</a> </h4> Hook resolution follows this order (highest to lowest): FieldHookProvider</code>: per-field hooks on the options struct</li> RegisterType</code> / RegisterEnum</code>: per-type hooks in the global registry</li> Built-in registry: time.Duration</code>, zapcore.Level</code>, slog.Level</code>, etc.</li> </ol> Completion precedence: If a completion function is already registered on a flag before Define</code>, structcli preserves it.</li> If Define</code> auto-registers a FieldCompleter</code> hook, a later manual RegisterFlagCompletionFunc</code> on the same flag returns Cobra's already registered</code> error.</li> </ul> In values</a> we provide pflag.Value</code> implementations for standard types. See the custom types example</a> for a runnable demo of all three mechanisms, or the full example</a> for a complete CLI. 🧱 Built-in Custom Types§</a> </h3> Type</th> Description</th> Example Values</th> Special Features</th></tr></thead> zapcore.Level</code></td> Zap logging levels</td> debug</code>, info</code>, warn</code>, error</code>, dpanic</code>, panic</code>, fatal</code></td> Enum validation</td></tr> slog.Level</code></td> Standard library logging levels</td> debug</code>, info</code>, warn</code>, error</code>, error+2</code>, ...</td> Level offsets: ERROR+2</code>, INFO-4</code></td></tr> time.Duration</code></td> Time durations</td> 30s</code>, 5m</code>, 2h</code>, 1h30m</code></td> Go duration parsing</td></tr> []time.Duration</code></td> Duration slices</td> 30s,5m</code>, 1s,2m30s</code></td> Comma-separated / repeated flags</td></tr> []bool</code></td> Boolean slices</td> true,false,true</code></td> Comma-separated / repeated flags</td></tr> []uint</code></td> Unsigned integer slices</td> 1,2,3,42</code></td> Comma-separated / repeated flags</td></tr> []byte</code></td> Raw textual bytes</td> hello</code>, abc123</code></td> Raw textual input</td></tr> structcli.Hex</code></td> Hex-decoded textual input</td> 68656c6c6f</code>, 48656c6c6f</code></td> Hex decoding</td></tr> structcli.Base64</code></td> Base64-decoded textual input</td> aGVsbG8=</code>, YWJjMTIz</code></td> Base64 decoding</td></tr> net.IP</code></td> IP address</td> 127.0.0.1</code>, 10.42.0.10</code>, 2001:db8::1</code></td> IP parsing</td></tr> net.IPMask</code></td> IPv4 mask</td> 255.255.255.0</code>, ffffff00</code></td> Dotted or hex mask parsing</td></tr> net.IPNet</code></td> CIDR subnet</td> 10.42.0.0/24</code>, 2001:db8::/64</code></td> CIDR parsing</td></tr> []net.IP</code></td> IP slices</td> 10.0.0.1,10.0.0.2</code></td> Comma-separated / repeated flags</td></tr> []string</code></td> String slices</td> item1,item2,item3</code></td> Comma-separated</td></tr> []int</code></td> Integer slices</td> 1,2,3,42</code></td> Comma-separated</td></tr> map[string]string</code></td> String maps</td> env=prod,team=platform</code></td> key=value</code> pairs</td></tr> map[string]int</code></td> Integer maps</td> cpu=2,memory=4</code></td> key=value</code> pairs with int parsing</td></tr> map[string]int64</code></td> 64-bit integer maps</td> ok=1,fail=2</code></td> key=value</code> pairs with int64 parsing</td></tr> </tbody></table> Note on JSON output: net.IPMask</code> is a byte slice under the hood, so Go's encoding/json</code> renders it as base64 (for example 255.255.255.0</code> appears as ////AA==</code>). This is expected. All built-in types support: Command-line flags with validation and help text</li> Environment variables with automatic binding</li> Configuration files (YAML, JSON, TOML)</li> Type validation with helpful error messages</li> </ul> Slices and maps use the same contract across flags, env vars, and config. See examples/collections/main.go</a> for a runnable version of this example. type AdvancedOptions struct { Retries []uint `flag:"retries" flagenv:"true"` Backoffs []time.Duration `flag:"backoffs" flagenv:"true"` FeatureOn []bool `flag:"feature-on" flagenv:"true"` Labels map[string]string `flag:"labels" flagenv:"true"` Limits map[string]int `flag:"limits" flagenv:"true"` Counts map[string]int64 `flag:"counts" flagenv:"true"` }</code></pre>❯ myapp --retries 1,2,3 --backoffs 1s,5s --feature-on true,false --labels env=prod,team=platform --limits cpu=8,memory=16 --counts ok=10,fail=3 ❯ MYAPP_RETRIES=1,2,3 MYAPP_BACKOFFS=1s,5s MYAPP_FEATURE_ON=true,false MYAPP_LABELS=env=prod,team=platform MYAPP_LIMITS=cpu=8,memory=16 MYAPP_COUNTS=ok=10,fail=3 myapp ❯ go run examples/collections/main.go --config examples/collections/config.yaml</code></pre>retries: "1,2,3" backoffs: - 1s - 5s feature-on: "true,false" labels: env: prod team: platform limits: cpu: 8 memory: 16 counts: "ok=10,fail=3"</code></pre>🧰 Reusable Flag Kits§</a> </h3> The flagkit</code> package provides pre-built, embeddable flag structs that standardize common CLI flag declarations. Each type encapsulates one flag with an opinionated name, type, and default matching industry conventions. This gives AI agents and scripts a consistent vocabulary across CLIs built with structcli. import "github.com/leodido/structcli/flagkit" type LogsOptions struct { flagkit.Follow // --follow/-f (default: false) Service string `flag:"service" flagshort:"s" flagdescr:"Service name" flagrequired:"true"` } func (o *LogsOptions) Attach(c *cobra.Command) error { if err := structcli.Define(c, o); err != nil { return err } flagkit.AnnotateCommand(c) // marks flagkit-owned flags for doc generation return nil }</code></pre> Attach</code> is needed here because of the custom flagkit.AnnotateCommand</code> call. For structs without custom define-time logic, use structcli.Bind(cmd, opts)</code> instead: it handles both plain structs and Options</code> implementors. Available types: Type</th> Flag</th> Default</th> Description</th></tr></thead> Follow</code></td> --follow</code> / -f</code></td> false</code></td> Opt-in streaming (agents won't hang)</td></tr> LogLevel</code></td> --log-level</code></td> info</code></td> Log level via zapcore (alias for ZapLogLevel</code>)</td></tr> ZapLogLevel</code></td> --log-level</code></td> info</code></td> Log level backed by zapcore.Level</code></td></tr> SlogLogLevel</code></td> --log-level</code></td> info</code></td> Log level backed by slog.Level</code> (stdlib)</td></tr> Output</code></td> --output</code> / -o</code></td> text</code></td> Output format (string enum, user-registered)</td></tr> Verbose</code></td> --verbose</code> / -v</code></td> 0</code></td> Verbosity count (-v</code>, -vv</code>, -vvv</code>)</td></tr> DryRun</code></td> --dry-run</code></td> false</code></td> Preview without making changes</td></tr> Timeout</code></td> --timeout</code></td> 30s</code></td> Operation timeout (time.Duration</code>)</td></tr> Quiet</code></td> --quiet</code> / -q</code></td> false</code></td> Suppress non-essential output</td></tr> </tbody></table> When the generate</code> package detects flagkit annotations, it emits a "Development Notes" section in AGENTS.md guiding AI coding agents to prefer flagkit types over ad-hoc flag declarations. See go doc github.com/leodido/structcli/flagkit</code> for the full taxonomy and composition examples. 🎨 Beautiful, Organized Help Output§</a> </h3> Organize your --help</code> output into logical groups for better readability. ❯ go run examples/full/main.go --help # A demonstration of the structcli library with beautiful CLI features # # Usage: # full [flags] # full [command] # # Available Commands: # completion Generate the autocompletion script for the specified shell # help Help about any command # logs Show service logs # preset Demonstrate flag presets with validation and transformation # srv Start the server # usr User management # # Flags: # -h, --help help for full # # Utility Flags: # --dry # -v, --verbose count # # Global Flags: # --config string config file (fallbacks to: {/etc/full,{executable_dir}/.full,$HOME/.full,...}/config.{yaml,json,toml}) # --debug-options string[="text"] debug output format (text, json) # --jsonschema string[="true"] output JSON Schema and exit (bare: this command, =tree: full subtree) # --mcp serve MCP over stdio # # Reference: # config-keys List all configuration file keys # env-vars List all environment variable bindings</code></pre>❯ go run examples/full/main.go srv --help # Start the server with the specified configuration # # Usage: # full srv [flags] # full srv [command] # # Available Commands: # version Print version information # # Flags: # --apikey string API authentication key # --deep-setting string (default "default-deep-setting") # --deep.deeper.nodefault string # --deeper-setting string (default "default-deeper-setting") # -h, --help help for srv # --host string Server host (default "localhost") # -p, --port int Server port # --target-env string Set the target environment {dev,prod,staging} (default "dev") # # Database Flags: # --database.maxconns int Max database connections (default 10) # --db-url string Database connection URL # # Logging Flags: # --log-file string Log file path # --log-level zapcore.Level Set log level {debug,info,warn,error,dpanic,panic,fatal} (default info) # # Network Flags: # --advertise-cidr ipNet Advertised service subnet (CIDR) (default 127.0.0.0/24) # --bind-ip ip Bind interface IP (default 127.0.0.1) # --bind-mask ipMask Bind interface mask (default ffffff00) # --trusted-peers ipSlice Trusted peer IPs (comma separated) (default 127.0.0.2,127.0.0.3) # # Security Flags: # --token-base64 bytesBase64 Token bytes encoded as base64 (default aGVsbG8=) # --token-hex bytesHex Token bytes encoded as hex (default 68656c6c6f) # # Global Flags: # --config string config file (fallbacks to: {/etc/full,{executable_dir}/.full,$HOME/.full,...}/config.{yaml,json,toml}) # --debug-options string[="text"] debug output format (text, json) # --jsonschema string[="true"] output JSON Schema and exit (bare: this command, =tree: full subtree) # --mcp serve MCP over stdio # # Use "full srv [command] --help" for more information about a command.</code></pre>🌐 WebAssembly (WASM)§</a> </h3> structcli avoids reflect.Value.MethodByName</code> and reflect.Value.Call</code>, so the Go compiler's dead-code elimination (DCE) works correctly and WASM binaries stay lean. All features work under GOOS=wasip1 GOARCH=wasm</code> with the standard Go compiler, including custom type hooks (RegisterType[T]</code>, FieldHookProvider</code>), JSON Schema generation, structured errors, and debug output. Build and run any structcli program as WASM: GOOS=wasip1 GOARCH=wasm go build -o myapp.wasm . wasmtime run --dir=/ myapp.wasm serve --port 8080</code></pre> This means structcli CLIs can run in sandboxed WASM runtimes, edge functions, and browser-based environments. Combined with --jsonschema</code> and --mcp</code>, an agent can discover the CLI contract, call it in a sandboxed WASM runtime, and handle structured failures without ever touching the host OS. 🏷️ Available Struct Tags§</a> </h2> Use these tags in your struct fields to control the behavior: Tag</th> Description</th> Example</th></tr></thead> flag</code></td> Sets a custom name for the flag (otherwise, generated from the field name)</td> flag:"log-level"</code></td></tr> flagpreset</code></td> Defines CLI-only preset aliases for this field's flag. Each preset is <alias-flag-name>=<value-for-this-field-flag></code>. No env/config keys are created.</td> flagpreset:"logeverything=5;logquiet=0"</code></td></tr> flagshort</code></td> Sets a single-character shorthand for the flag</td> flagshort:"l"</code></td></tr> flagdescr</code></td> Provides the help text for the flag</td> flagdescr:"Logging level"</code></td></tr> default</code></td> Sets the default value for the flag</td> default:"info"</code></td></tr> flagenv</code></td> Enables binding to an environment variable ("true"</code>, "false"</code>, or "only"</code>)</td> flagenv:"true"</code></td></tr> flagrequired</code></td> Marks the flag as required ("true"</code>/"false"</code>)</td> flagrequired:"true"</code></td></tr> flaghidden</code></td> Hides the flag from help/usage output and machine-readable schemas while keeping it fully functional ("true"</code>/"false"</code>)</td> flaghidden:"true"</code></td></tr> flaggroup</code></td> Assigns the flag to a group in the help message</td> flaggroup:"Database"</code></td></tr> flagignore</code></td> Skips creating a flag for this field ("true"</code>/"false"</code>)</td> flagignore:"true"</code></td></tr> flagtype</code></td> Specifies a special flag type. Currently supports count</code></td> flagtype:"count"</code></td></tr> </tbody></table> flagpreset</code> is syntactic sugar: it creates alias flags that set the canonical flag value. Format: <alias>=<value></code>; multiple entries can be separated by ;</code> or ,</code>. Example: flagpreset:"logeverything=5;logquiet=0"</code> makes --logeverything</code> behave like --loglevel=5</code>. If both alias and canonical flags are passed, the last assignment in argv wins. It does not bypass transform/validate flow. flaghidden:"true" + flagenv:"true"</code> vs flagenv:"only"</code>: flaghidden:"true" + flagenv:"true"</code>: hidden from help, but accepts CLI input via --flag=value</code>. Use for flags that should be discoverable only by advanced users or scripts.</li> flagenv:"only"</code>: hidden from help, rejects CLI input at runtime. The field is settable only via environment variable or config file. Use for secrets and deployment-time configuration that should never appear on a command line.</li> </ul> flagenv:"only"</code> is incompatible with flagshort</code>, flagpreset</code>, and flagtype</code> (these are CLI-only concepts). It supports flagdescr</code>, flaggroup</code>, flagrequired</code>, and default</code>. FieldHookProvider</code> Define/Decode hooks work normally on flagenv:"only"</code> fields (the flag is created then hidden). FieldCompleter</code> hooks are skipped since hidden flags have no CLI completion. 📖 Documentation§</a> </h2> For comprehensive documentation and advanced usage patterns, visit the documentation</a>. Start here for repo-local guides: AI-Native CLIs guide</a></li> Structured error example walkthrough</a></li> Examples directory</a></li> </ul> 🤝 Contributing§</a> </h2> Contributions are welcome! Please feel free to submit a Pull Request. go-conventionalcommits 2020-11-18T00:00:00+00:00 This repository provides a library to parse your commit messages according to the Conventional Commits v1.0 specification. Installation§</a> </h2> go get github.com/leodido/go-conventionalcommits</code></pre>Docs§</a> </h2> The parser/docs</a> directory contains .dot</code> and .png</code> files representing the finite-state machines (FSMs) implementing the parser. Usage§</a> </h2> Parse§</a> </h3> Your code base uses only single line commit messages like this one? feat: awesomeness</code></pre> No problem at all since the body and the footer parts are not mandatory: m, _ := parser.NewMachine().Parse([]byte(`feat: awesomeness`))</code></pre>Full conventional commit messages§</a> </h3> Imagine you have a commit message like this: docs: correct minor typos see the issue for details on docs edits. Reviewed-by: Z Refs #133</code></pre> Go with this: opts := []conventionalcommits.MachineOption{ WithTypes(conventionalcommits.TypesConventional), } res, err := parser.NewMachine(opts...).Parse(i)</code></pre> Or, more simpler: res, err := parser.NewMachine(WithTypes(conventionalcommits.TypesConventional)).Parse(i)</code></pre>Types§</a> </h3> This library provides support for different types sets: minimal: fix, feat</li> conventional: build, ci, chore, docs, feat, fix, perf, refactor, revert, style, test</li> falco: build, ci, chore, docs, feat, fix, perf, new, revert, update, test, rule</li> </ul> At the moment, those types are at build time. Which means users can't configure them at runtime. Anyway, there's also a free-form types set that accepts any combination of printable characters (before the separator after which the commit description starts) as a valid type. You can choose the type set passing the WithTypes(conventionalcommits.TypesConventional)</code> option as shown above. Options§</a> </h3> A parser behaviour is configurable by using options. You can set them calling a function on the parser machine. p := parser.NewMachine() p.WithBestEffort() res, err := p.Parse(i)</code></pre> Or you can provide options to NewMachine(...)</code> directly. p := parser.NewMachine(WithBestEffort()) res, err := p.Parse(i)</code></pre>Best effort§</a> </h3> The best effort mode will make the parser return what it found until the point it errored out, if it found (at least) a valid type and a valid description. Let's make an example. Suppose this input commit message: fix: description a blank line is mandatory to start the body part of the commit message!</code></pre> The input does not respect the Conventional Commits v1 specification because it lacks a blank line after the description (before the body). Anyways, if the parser you're using has the best effort mode enabled, you can still obtain some structured data since at least a valid type and description have been found! res, err := parser.NewMachine(WithBestEffort()).Parse(i)</code></pre> The result will contain a ConventionalCommit</code> struct instance with the Type</code> and the Description</code> fields populated and ignore the rest after the error column. The parser will still return the error (with the position information), so that you can eventually use it. Trailer parsing§</a> </h2> The parser implements Conventional Commits v1.0 clauses 8 to 10</a> for trailers (also called footers). A few behaviors are worth calling out. Trailer-shaped lines in the body stay in the body§</a> </h3> A line in the body that looks like a trailer (say, Fixes #123</code>) is not picked up as one. The trailer block is only the run of trailer lines at the end of the message, with a blank line between it and the body. Given this commit message: fix: x This paragraph mentions Fixes #123 in passing. Reviewed-by: X</code></pre>in := []byte("fix: x\n\nThis paragraph mentions\nFixes #123 in passing.\n\nReviewed-by: X") m, _ := parser.NewMachine(parser.WithTypes(conventionalcommits.TypesFreeForm)).Parse(in) // m.Body == "This paragraph mentions\nFixes #123 in passing." // m.Footers == map[reviewed-by:[X]]</code></pre> A message whose body ends with a trailer-shaped line but has no real trailer block keeps the line as body content: fix: x This paragraph mentions Fixes #123 in passing.</code></pre>in := []byte("fix: x\n\nThis paragraph mentions\nFixes #123 in passing.") m, _ := parser.NewMachine(parser.WithTypes(conventionalcommits.TypesFreeForm)).Parse(in) // m.Body == "This paragraph mentions\nFixes #123 in passing." // m.Footers == map[]</code></pre>Multi-line trailer values§</a> </h3> Clause 10 says a trailer's value can contain spaces and newlines. The value keeps going until the parser sees the next trailer (a Token: value</code> line) or a blank line. Given this commit message: fix: x BREAKING CHANGE: this is a long explanation that wraps across several lines Reviewed-by: X</code></pre>in := []byte("fix: x\n\nBREAKING CHANGE: this is a long\n explanation that wraps\n across several lines\nReviewed-by: X") m, _ := parser.NewMachine(parser.WithTypes(conventionalcommits.TypesFreeForm)).Parse(in) // m.Footers == map[ // breaking-change: ["this is a long\n explanation that wraps\n across several lines"] // reviewed-by: ["X"] // ]</code></pre>Blank-separated trailers§</a> </h3> Clause 8 lets you put a blank line between trailers. Both layouts parse the same way. Blank-separated: feat: x Fixes #1 Reviewed-by: X</code></pre> Adjacent: feat: x Fixes #1 Reviewed-by: X</code></pre>parser.NewMachine(...).Parse([]byte("feat: x\n\nFixes #1\n\nReviewed-by: X")) parser.NewMachine(...).Parse([]byte("feat: x\n\nFixes #1\nReviewed-by: X")) // Both yield: footers == map[fixes:[1] reviewed-by:[X]]</code></pre>What Parse</code> returns§</a> </h3> In strict mode (best-effort off), Parse</code> returns one of: (*ConventionalCommit, nil)</code> on success</li> (nil, error)</code> on failure</li> </ul> It never returns (nil, nil)</code>, so a nil</code> first value always means the second value is the real error. In best-effort mode you can also get (*ConventionalCommit, error)</code>: a partial commit recovered before the parser ran into the problem, plus the error telling you where it stopped. Performances§</a> </h2> To run the benchmark suite execute the following command. make bench</code></pre> All the parsers have the best effort mode on. On my machine1</a>, these are the results for the slim</code> parser with the default - ie., minimal</code>, commit message types. [ok]_minimal______________________________________-12 4876018 242 ns/op 147 B/op 5 allocs/op [ok]_minimal_with_scope___________________________-12 4258562 284 ns/op 163 B/op 6 allocs/op [ok]_minimal_breaking_with_scope__________________-12 4176747 288 ns/op 163 B/op 6 allocs/op [ok]_full_with_50_characters_long_description_____-12 1661618 700 ns/op 288 B/op 10 allocs/op [no]_empty________________________________________-12 4059327 292 ns/op 112 B/op 3 allocs/op [no]_type_but_missing_colon_______________________-12 2701904 444 ns/op 200 B/op 6 allocs/op [no]_type_but_missing_description_________________-12 2207985 539 ns/op 288 B/op 8 allocs/op [no]_type_and_scope_but_missing_description_______-12 1969390 605 ns/op 312 B/op 10 allocs/op [no]_breaking_with_type_and_scope_but_missing_desc-12 1978302 606 ns/op 312 B/op 10 allocs/op [~~]_newline_in_description_______________________-12 2115649 563 ns/op 232 B/op 11 allocs/op [no]_missing_whitespace_in_description____________-12 1997863 595 ns/op 312 B/op 10 allocs/op</code></pre> Using another set of commit message types, for example the conventional</code> one, does not have any noticeable impact on performances, as you can see below. [ok]_minimal______________________________________-12 5297486 228 ns/op 147 B/op 5 allocs/op [ok]_minimal_with_scope___________________________-12 4498694 267 ns/op 163 B/op 6 allocs/op [ok]_minimal_breaking_with_scope__________________-12 4431040 273 ns/op 163 B/op 6 allocs/op [ok]_full_with_50_characters_long_description_____-12 1750111 692 ns/op 288 B/op 10 allocs/op [no]_empty________________________________________-12 3996532 294 ns/op 112 B/op 3 allocs/op [no]_type_but_missing_colon_______________________-12 2657913 451 ns/op 200 B/op 6 allocs/op [no]_type_but_missing_description_________________-12 2172524 553 ns/op 288 B/op 8 allocs/op [no]_type_and_scope_but_missing_description_______-12 1880526 637 ns/op 312 B/op 10 allocs/op [no]_breaking_with_type_and_scope_but_missing_desc-12 1879779 635 ns/op 312 B/op 10 allocs/op [~~]_newline_in_description_______________________-12 2023514 592 ns/op 232 B/op 11 allocs/op [no]_missing_whitespace_in_description____________-12 1883124 623 ns/op 312 B/op 10 allocs/op</code></pre> As you may notice, this library is very fast at what it does. Parsing a commit goes from taking about the same amount of time (~299ns) the half-life of polonium-212 takes2</a> to less than a microsecond. Build§</a> </h2> To build this Go library locally just run: make</code></pre> You'd need Ragel 6.10 to be present into your machine. [1]</a>: Intel Core i7-8850H CPU @ 2.60GHz</li> [2]</a>: https://en.wikipedia.org/wiki/nanosecond</a></li> </ul> kubectl-trace 2018-11-21T00:00:00+00:00 kubectl trace</code> is a kubectl plugin that allows you to schedule the execution of bpftrace</a> programs in your Kubernetes cluster. Installing§</a> </h2> Krew§</a> </h3> You can install kubectl trace</code> using the Krew</a>, the package manager for kubectl plugins. Once you have Krew installed</a> just run: kubectl krew install trace</code></pre> You're ready to go! Pre-built binaries§</a> </h3> See the release</a> page for the full list of pre-built assets. The commands here show amd64</code> versions, 386</code> versions are available in the releases page. Linux curl -L -o kubectl-trace.tar.gz https://github.com/iovisor/kubectl-trace/releases/download/v0.1.0-rc.1/kubectl-trace_0.1.0-rc.1_linux_amd64.tar.gz tar -xvf kubectl-trace.tar.gz mv kubectl-trace /usr/local/bin/kubectl-trace</code></pre> OSX curl -L -o kubectl-trace.tar.gz https://github.com/iovisor/kubectl-trace/releases/download/v0.1.0-rc.1/kubectl-trace_0.1.0-rc.1_darwin_amd64.tar.gz tar -xvf kubectl-trace.tar.gz mv kubectl-trace /usr/local/bin/kubectl-trace</code></pre> Windows In PowerShell v5+ $url = "https://github.com/iovisor/kubectl-trace/releases/download/v0.1.0-rc.1/kubectl-trace_0.1.0-rc.1_windows_amd64.zip" $output = "$PSScriptRoot\kubectl-trace.zip" Invoke-WebRequest -Uri $url -OutFile $output Expand-Archive "$PSScriptRoot\kubectl-trace.zip" -DestinationPath "$PSScriptRoot\kubectl-trace"</code></pre>Source§</a> </h3> Using go modules, you can build kubectl-trace at any git tag: GO111MODULE=on go get github.com/iovisor/kubectl-trace/cmd/kubectl-trace@latest</code></pre> This will download and compile kubectl-trace</code> so that you can use it as a kubectl plugin with kubectl trace</code>, note that you will need to be on a recent version of go which supports go modules. To keep track of the ref you used to build, you can add an ldflag at build time to set this to match the ref provided to go modules: > GO111MODULE=on go get -ldflags='-X github.com/iovisor/kubectl-trace/pkg/version.gitCommit=v0.1.2' github.com/iovisor/kubectl-trace/cmd/kubectl-trace@v0.1.2 > $GOHOME/bin/kubectl-trace version git commit: v0.1.2 build date: 2021-08-10 12:38:37.921341766 -0400 EDT m=+0.034327432</code></pre> Note: It is recommended you build tagged revisions only if you are looking for stability. Building branches such as master</code> or the latest</code> tag may result in a more unstable build which has received less QA than a tagged release. Packages§</a> </h3> You can't find the package for your distro of choice? You are very welcome and encouraged to create it and then open an issue</a> to inform us for review. Arch - AUR§</a> </h4> The official PKGBUILD</a> is on AUR. If you use yay</code> to manage AUR packages you can do: yay -S kubectl-trace-git</code></pre>Architecture§</a> </h2> See architecture.md</a> Usage§</a> </h2> You don't need to setup anything on your cluster before using it, please don't use it already on a production system, just because this isn't yet 100% ready. Run a program from string literal§</a> </h3> In this case we are running a program that probes a tracepoint on the node ip-180-12-0-152.ec2.internal</code>. kubectl trace run ip-180-12-0-152.ec2.internal -e "tracepoint:syscalls:sys_enter_* { @[probe] = count(); }"</code></pre>Run a program from file§</a> </h3> Here we run a program named read.bt</code> against the node ip-180-12-0-152.ec2.internal</code> kubectl trace run ip-180-12-0-152.ec2.internal -f read.bt</code></pre>Run a program against a Pod§</a> </h3> That pod has a Go program in it that is at /caturday</code>, that program has a function called main.counterValue</code> in it that returns an integer every time it is called. The purpose of this program is to load an uretprobe</code> on the /caturday</code> binary so that every time the main.counterValue</code> function is called we get the return value out. Since kubectl trace</code> for pods is just an helper to resolve the context of a container's Pod, you will always be in the root namespaces but in this case you will have a variable $container_pid</code> containing the pid of the root process in that container on the root pid namespace. What you do then is that you get the /caturday</code> binary via /proc/$container_pid/exe</code>, like this: kubectl trace run -e 'uretprobe:/proc/$container_pid/exe:"main.counterValue" { printf("%d\n", retval) }' pod/caturday-566d99889-8glv9 -a -n caturday</code></pre>Running against a Pod vs against a Node§</a> </h3> In general, you run kprobes/kretprobes, tracepoints, software, hardware and profile events against nodes using the node/node-name</code> syntax or just use the node name, node is the default. When you want to actually probe an userspace program with an uprobe/uretprobe or use an user-level static tracepoint (usdt) your best bet is to run it against a pod using the pod/pod-name</code> syntax. It's always important to remember that running a program against a pod, as of now, is just a facilitator to find the process id for the binary you want to probe on the root process namespace. You could do the same thing when running in a Node by knowing the pid of your process yourself after entering in the node via another medium, e.g: ssh. So, running against a pod doesn't mean that your bpftrace program will be contained in that pod but just that it will pass to your program some knowledge of the context of a container, in this case only the root process id is supported via the $container_pid</code> variable. Using a custom service account§</a> </h3> By default kubectl trace</code> will use the default</code> service account in the target namespace (that is also default</code>), to schedule the pods needed for your bpftrace program. If you need to pass a service account you can use the --serviceaccount</code> flag. kubectl trace run --serviceaccount=kubectltrace ip-180-12-0-152.ec2.internal -f read.bt</code></pre>Executing in a cluster using Pod Security Policies§</a> </h3> If your cluster has pod security policies you will need to make so that kubectl trace</code> can use a service account that can run privileged containers. That service account, then will need to be in a group that uses the proper privileged PodSecurityPolicy</code>. First, create the service account that you will use with kubectl trace</code>, you can use a different namespace other than default</code>, just remember to pass that namespace to the run</code> command when you will use kubectl trace</code>: apiVersion: v1 kind: ServiceAccount metadata: name: kubectltrace namespace: default</code></pre> Now that we have a kubectltrace</code> service account let's create a Pod Security Policy: apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: kubectltrace spec: fsGroup: rule: RunAsAny privileged: true runAsUser: rule: RunAsAny seLinux: rule: RunAsAny supplementalGroups: rule: RunAsAny volumes: - '*' allowedCapabilities: - '*' hostPID: true hostIPC: true hostNetwork: true hostPorts: - min: 1 max: 65536</code></pre> Ok, this PodSecurityPolicy</code> will allow users assigned to it to run privileged containers, kubectl trace</code> needs that because of the extended privileges eBPF programs need to run with to trace your kernel and programs running in it. Now with a ClusterRoleBinding</code> you bind the ClusterRole</code> with the ServiceAccount</code>, so that they can work together with the PodSecurityPolicy</code> we just created. You can change the namespace: default</code> here if you created the service account in a namespace other than default</code>. apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: kubectltrace-psp rules: - apiGroups: - policy resources: - podsecuritypolicies resourceNames: - kubectltrace verbs: - use apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kubectltrace-psp subjects: - kind: ServiceAccount name: kubectltrace namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: kubectltrace-psp</code></pre> OK! Now that we are all set we can just run the program by specifying the service account we just created and it will use our pod security policy! kubectl trace run --serviceaccount=kubectltrace ip-180-12-0-152.ec2.internal -f read.bt</code></pre> If you used a different namespace other than default for your service account, you will want to specify the namespace too, like this: kubectl trace run --namespace=mynamespace --serviceaccount=kubectltrace ip-180-12-0-152.ec2.internal -f read.bt</code></pre>Using a patch to customize the trace job§</a> </h3> There may be times when you need to customize the job descriptor that kubectl-trace generates. You can provide a patch file that will modify any of the job's attributes before it executes on the cluster. The --patch</code> and --patch-type</code> arguments to the run</code> command specify your patch file's location and merge strategy: --patch</code> - sets the path to a YAML or JSON file containing your patch.</li> --patch-type</code> - sets the strategy that will be used to modify the job descriptor.</li> </ul> Patch strategies The supported patch strategies are the same as those used by Kubernetes to support in-place API object updates</a>. These 3 patch strategies are: json</code> - Sets the JSON patch</a> strategy (see RFC 6209</a>).</li> merge</code> - Sets the JSON merge patch</a> strategy.</li> strategic</code> - JSON strategic merge patch is like the "JSON merge patch" but with different array handling (see Kubernetes strategic merge</a> for more).</li> </ul> Note: You can create your patch files in either YAML or JSON format. The format is independent of the strategy used, e.g. the strategy json</code> refers to the "JSON patch" strategy, not the format of the patch file. Example: customizing resource limits A cluster administrator may have set strict resource limits that conflict with the defaults used by kubectl-trace</code>, preventing your job from executing. With a patch you can adjust a job's resource limits to match your cluster's config. Below is an example of a YAML patch which uses the json</code> strategy ("JSON patch"). This strategy consists of a list of operations (add, replace, remove), a path which references a location in the document, and an optional value (to add or replace). The patch below replaces the first container's resources section, in order to increase both the request and limit values for cpu and memory: # mypatch.yaml - op: replace path: /spec/template/spec/containers/0/resources value: limits: cpu: 2 memory: 500Mi requests: cpu: 2 memory: 500Mi</code></pre> We can now run the job using our patch: kubectl trace run ip-180-12-0-152.ec2.internal -f read.bt --patch mypatch.yaml --patch-type json</code></pre> Example: setting an environment variable The following JSON format patch adds a BPFTRACE_STRLEN</code> environment variable to the first container. The variable increases bpftrace</code>'s string length limit from 64 to 128: [ { "op": "add", "path": "/spec/template/spec/containers/0/env", "value": [{ "name": "BPFTRACE_STRLEN", "value": "128" }] } ]</code></pre>kubectl trace run ip-180-12-0-152.ec2.internal -f read.bt --patch mypatch.json --patch-type json</code></pre>More bpftrace programs§</a> </h3> Need more programs? Look here</a>. Contributing§</a> </h2> Already pumped up to commit some code? Here are some resources to join the discussions in the IOVisor</a> community and see what you want to work on. Mailing List: http://lists.iovisor.org/mailman/listinfo/iovisor-dev</li> IRC: #iovisor at irc.oftc.net</li> Slack #kubectl-trace in the Kubernetes Slack</a></li> Kubectl Trace Issue Tracker: Github Issues</a></li> </ul> Special thanks to Ramon Gilabert</a> for the logo. go-syslog 2018-03-28T00:00:00+00:00 This is the official continuation of influxdata/go-syslog. To wrap up, this package provides: an RFC5424-compliant parser and builder</a></li> an RFC3164-compliant parser</a> - ie., BSD-syslog messages</li> an auto-detect parser</a> that determines RFC 3164 vs RFC 5424 format per-message</li> an RFC3195 parser</a> for syslog over BEEP</a> (RAW and COOKED profiles)</li> a parser that works on streams for syslog with octet counting</a> framing technique, see octetcounting</a></li> a parser that works on streams for syslog with non-transparent</a> framing technique, see nontransparent</a></li> </ul> This library provides the pieces to parse Syslog messages transported following various RFCs. For example: TLS with octet count (RFC5425</a>)</li> TCP with non-transparent framing or with octet count (RFC 6587</a>)</li> UDP carrying one message per packet (RFC5426</a>)</li> </ul> Installation§</a> </h2> Requires Go 1.22 or later. go get github.com/leodido/go-syslog/v4</code></pre>Docs§</a> </h2> The docs</a> directory contains .dot</code> files representing the finite-state machines (FSMs) implementing the syslog parsers and transports. Usage§</a> </h2> Suppose you want to parse a given sequence of bytes as a RFC5424 message. Notice that the same interface applies for RFC3164. But you can always take a look at the examples file</a>. i := []byte(`<165>4 2018-10-11T22:14:15.003Z mymach.it e - 1 [ex@32473 iut="3"] An application event log entry...`) p := rfc5424.NewParser() m, e := p.Parse(i)</code></pre> This results in m</code> being equal to: // (*rfc5424.SyslogMessage)({ // Base: (syslog.Base) { // Facility: (*uint8)(20), // Severity: (*uint8)(5), // Priority: (*uint8)(165), // Timestamp: (*time.Time)(2018-10-11 22:14:15.003 +0000 UTC), // Hostname: (*string)((len=9) "mymach.it"), // Appname: (*string)((len=1) "e"), // ProcID: (*string)(<nil>), // MsgID: (*string)((len=1) "1"), // Message: (*string)((len=33) "An application event log entry...") // }, // Version: (uint16) 4, // StructuredData: (*map[string]map[string]string)((len=1) { // (string) (len=8) "ex@32473": (map[string]string) (len=1) { // (string) (len=3) "iut": (string) (len=1) "3" // } // }) // })</code></pre> And e</code> being equal to nil</code> since the i</code> byte slice contains a perfectly valid RFC5424 message. Best effort mode§</a> </h3> RFC5424 parser has the ability to perform partial matches (until it can). With this mode enabled, when the parsing process errors out it returns the message collected until that position, and the error that caused the parser to stop. Notice that in this modality the output is returned iff it represents a minimally valid message - ie., a message containing almost a priority field in [1,191]</code> within angular brackets, followed by a version in ]0,999]</code> (in the case of RFC5424). Let's look at an example. i := []byte("<1>1 A - - - - - -") p := rfc5424.NewParser(rfc5424.WithBestEffort()) m, e := p.Parse(i)</code></pre> This results in m</code> being equal to the following SyslogMessage</code> instance. // (*rfc5424.SyslogMessage)({ // Base: (syslog.Base) { // Facility: (*uint8)(0), // Severity: (*uint8)(1), // Priority: (*uint8)(1), // Timestamp: (*time.Time)(<nil>), // Hostname: (*string)(<nil>), // Appname: (*string)(<nil>), // ProcID: (*string)(<nil>), // MsgID: (*string)(<nil>), // Message: (*string)(<nil>) // }, // Version: (uint16) 1, // StructuredData: (*map[string]map[string]string)(<nil>) // })</code></pre> And, at the same time, in e</code> reporting the error that actually stopped the parser. // expecting a RFC3339MICRO timestamp or a nil value [col 5]</code></pre> Both m</code> and e</code> have a value since at the column the parser stopped it already was able to construct a minimally valid RFC5424 SyslogMessage</code>. Builder§</a> </h3> This library also provides a builder to construct valid syslog messages. Notice that its API ignores input values that does not match the grammar. Let's have a look to an example. msg := &rfc5424.SyslogMessage{} msg.SetTimestamp("not a RFC3339MICRO timestamp") msg.Valid() // Not yet a valid message (try msg.Valid()) msg.SetPriority(191) msg.SetVersion(1) msg.Valid() // Now it is minimally valid</code></pre> Printing msg</code> you will verify it contains a nil</code> timestamp (since an invalid one has been given). // (*rfc5424.SyslogMessage)({ // Base: (syslog.Base) { // Facility: (*uint8)(23), // Severity: (*uint8)(7), // Priority: (*uint8)(191), // Timestamp: (*time.Time)(<nil>), // Hostname: (*string)(<nil>), // Appname: (*string)(<nil>), // ProcID: (*string)(<nil>), // MsgID: (*string)(<nil>), // Message: (*string)(<nil>) // }, // Version: (uint16) 1, // StructuredData: (*map[string]map[string]string)(<nil>) // })</code></pre> Finally you can serialize the message into a string. str, _ := msg.String() // <191>1 - - - - - -</code></pre>Auto-detect§</a> </h3> Suppose you don't know whether incoming messages are RFC 5424 or RFC 3164. The auto</a> package figures it out per-message. m := auto.NewMachine() msg, err := m.Parse(input) fmt.Println(auto.DetectFormat(msg)) // "rfc5424" or "rfc3164"</code></pre> You can pass format-specific options to each inner parser: m := auto.NewMachine( auto.WithRFC3164Options(rfc3164.WithYear(rfc3164.Year{YYYY: 2025})), auto.WithRFC5424Options(rfc5424.WithCompliantMsg()), )</code></pre> It also works with the stream parsers via NewParserAuto</code> - see octet counting</a> and non-transparent</a> below. Performance-wise, auto-detect peeks at a few bytes after the PRI to pick the format - no allocations, no copying. It's as fast as calling the right parser yourself. Message transfer§</a> </h2> Excluding encapsulating one message for packet in packet protocols there are two ways to transfer syslog messages over streams. The older - ie., the non-transparent framing - and the newer one - ie., the octet counting framing - which is reliable and has not been seen to cause problems noted with the non-transparent one. This library provide stream parsers for both. Octet counting§</a> </h3> In short, RFC5425</a> and RFC6587</a>, aside from the protocol considerations, describe a transparent framing technique for Syslog messages that uses the octect counting technique - ie., the message length of the incoming message. Each Syslog message is sent with a prefix representing the number of bytes it is made of. The octecounting package</a> parses messages stream following such rule. To quickly understand how to use it please have a look at the example file</a>. If you have mixed RFC 5424 and RFC 3164 messages in the same stream, use NewParserAuto</code>: p := octetcounting.NewParserAuto( syslog.WithListener(func(r *syslog.Result) { fmt.Println(auto.DetectFormat(r.Message)) }), syslog.WithBestEffort(), ) p.Parse(reader)</code></pre>Non transparent§</a> </h3> The RFC6587</a> also describes the non-transparent framing transport of syslog messages. In such case the messages are separated by a trailer, usually a line feed. The nontransparent package</a> parses message stream following such technique</a>. To quickly understand how to use it please have a look at the example file</a>. Same as octet counting, use NewParserAuto</code> for mixed-format streams: p := nontransparent.NewParserAuto( syslog.WithListener(func(r *syslog.Result) { fmt.Println(auto.DetectFormat(r.Message)) }), syslog.WithBestEffort(), ) p.Parse(reader)</code></pre> Things we do not support: trailers other than LF</code> or NUL</code></li> trailers which length is greater than 1 byte</li> trailer change on a frame-by-frame basis</li> </ul> RFC 3195 (BEEP)§</a> </h3> RFC 3195</a> defines syslog transport over the BEEP</a> protocol. It specifies two profiles: RAW (§4.2): syslog messages are carried as CRLF-terminated payloads in BEEP ANS frames. The inner messages can be either RFC 5424 or RFC 3164 format.</li> COOKED (§4.3): syslog data is encoded as XML <entry></code> elements with attributes for facility, severity, timestamp, tag, and device identity.</li> </ul> The rfc3195 package</a> provides parsers for both profiles. It implements BEEP frame scanning (MSG, RPY, ERR, ANS, NUL, SEQ frames) and extracts syslog messages from the frame payloads. This is a parsing-only implementation - it does not handle BEEP session management, channel negotiation, or TLS. Feed it a stream of BEEP frames and it will emit parsed syslog messages. To quickly understand how to use it please have a look at the example file</a>. Performances§</a> </h2> To run the benchmark execute the following command. make bench</code></pre> On my machine1</a> these are the results obtained paring RFC5424 syslog messages with best effort mode on. [no]_empty_input__________________________________-10 32072733 185.3 ns/op 272 B/op 4 allocs/op [no]_multiple_syslog_messages_on_multiple_lines___-10 27058381 219.8 ns/op 267 B/op 7 allocs/op [no]_impossible_timestamp_________________________-10 8732960 683.8 ns/op 555 B/op 12 allocs/op [no]_malformed_structured_data____________________-10 17997814 335.6 ns/op 499 B/op 8 allocs/op [no]_with_duplicated_structured_data_id___________-10 9254920 645.7 ns/op 672 B/op 15 allocs/op [ok]_minimal______________________________________-10 48347473 123.2 ns/op 227 B/op 5 allocs/op [ok]_average_message______________________________-10 6058492 986.8 ns/op 1344 B/op 20 allocs/op [ok]_complicated_message__________________________-10 7052536 843.2 ns/op 1232 B/op 23 allocs/op [ok]_very_long_message____________________________-10 2644068 2279.0 ns/op 2272 B/op 21 allocs/op [ok]_all_max_length_and_complete__________________-10 3611186 1675.0 ns/op 1848 B/op 27 allocs/op [ok]_all_max_length_except_structured_data_and_mes-10 5729514 1059.0 ns/op 851 B/op 12 allocs/op [ok]_minimal_with_message_containing_newline______-10 43165338 142.9 ns/op 230 B/op 6 allocs/op [ok]_w/o_procid,_w/o_structured_data,_with_message-10 14832892 397.8 ns/op 308 B/op 9 allocs/op [ok]_minimal_with_UTF-8_message___________________-10 20229313 306.2 ns/op 339 B/op 6 allocs/op [ok]_minimal_with_UTF-8_message_starting_with_BOM_-10 19721539 306.7 ns/op 355 B/op 6 allocs/op [ok]_with_structured_data_id,_w/o_structured_data_-10 13860580 435.7 ns/op 538 B/op 10 allocs/op [ok]_with_multiple_structured_data________________-10 8368731 721.9 ns/op 1173 B/op 15 allocs/op [ok]_with_escaped_backslash_within_structured_data-10 9730569 632.6 ns/op 864 B/op 16 allocs/op [ok]_with_UTF-8_structured_data_param_value,_with_-10 8864156 660.6 ns/op 858 B/op 15 allocs/op</code></pre> As you can see it takes: ~125ns to parse the smallest legal message </li> less than 1µs to parse an average legal message </li> ~2µs to parse a very long legal message </li> </ul> Other RFC5424 implementations, like this one</a> in Rust, spend 8µs to parse an average legal message. [1]</a>: Apple M1 Pro</li> </ul> go-urn 2017-11-21T00:00:00+00:00 Starting with version 1.3 this library also supports RFC 7643 SCIM URNs</a>. Starting with version 1.4 this library also supports RFC 8141 URNs (2017)</a>. Installation§</a> </h2> go get github.com/leodido/go-urn</code></pre>Features§</a> </h2> RFC 2141 URNs parsing (default)</li> RFC 8141 URNs parsing (supersedes RFC 2141)</li> RFC 7643 SCIM URNs parsing</li> Normalization as per RFCs</li> Lexical equivalence as per RFCs</li> Precise, fine-grained errors</li> </ol> Performances§</a> </h2> This implementation results to be really fast. Usually below 400 ns on my machine1</a>. Notice it also performs, while parsing: fine-grained and informative erroring</li> specific-string normalization</li> </ol> ok/00/urn:a:b______________________________________/-10 51372006 109.0 ns/op 275 B/op 3 allocs/op ok/01/URN:foo:a123,456_____________________________/-10 36024072 160.8 ns/op 296 B/op 6 allocs/op ok/02/urn:foo:a123%2C456___________________________/-10 31901007 188.4 ns/op 320 B/op 7 allocs/op ok/03/urn:ietf:params:scim:schemas:core:2.0:User___/-10 22736756 266.6 ns/op 376 B/op 6 allocs/op ok/04/urn:ietf:params:scim:schemas:extension:enterp/-10 18291859 335.2 ns/op 408 B/op 6 allocs/op ok/05/urn:ietf:params:scim:schemas:extension:enterp/-10 15283087 379.4 ns/op 440 B/op 6 allocs/op ok/06/urn:burnout:nss______________________________/-10 39407593 155.1 ns/op 288 B/op 6 allocs/op ok/07/urn:abcdefghilmnopqrstuvzabcdefghilm:x_______/-10 27832718 211.4 ns/op 307 B/op 4 allocs/op ok/08/urn:urnurnurn:urn____________________________/-10 33269596 168.1 ns/op 293 B/op 6 allocs/op ok/09/urn:ciao:!!*_________________________________/-10 41100675 148.8 ns/op 288 B/op 6 allocs/op ok/10/urn:ciao:=@__________________________________/-10 37214253 149.7 ns/op 284 B/op 6 allocs/op ok/11/urn:ciao:@!=%2C(xyz)+a,b.*@g=$_'_____________/-10 26534240 229.8 ns/op 336 B/op 7 allocs/op ok/12/URN:x:abc%1Dz%2F%3az_________________________/-10 28166396 211.8 ns/op 336 B/op 7 allocs/op no/13/URN:---xxx:x_________________________________/-10 23635159 255.6 ns/op 419 B/op 5 allocs/op no/14/urn::colon:nss_______________________________/-10 23594779 258.4 ns/op 419 B/op 5 allocs/op no/15/URN:@,:x_____________________________________/-10 23742535 261.5 ns/op 419 B/op 5 allocs/op no/16/URN:URN:NSS__________________________________/-10 27432714 223.3 ns/op 371 B/op 5 allocs/op no/17/urn:UrN:NSS__________________________________/-10 26922117 224.9 ns/op 371 B/op 5 allocs/op no/18/urn:a:%______________________________________/-10 24926733 224.6 ns/op 371 B/op 5 allocs/op no/19/urn:urn:NSS__________________________________/-10 27652641 220.7 ns/op 371 B/op 5 allocs/op</code></pre> [1]</a>: Apple M1 Pro</li> </ul> Example§</a> </h2> For more examples take a look at the examples file</a>. package main import ( "fmt" "github.com/leodido/go-urn" ) func main() { var uid = "URN:foo:a123,456" // Parse the input string as a RFC 2141 URN only u, e := urn.NewMachine().Parse(uid) if e != nil { fmt.Errorf(err) return } fmt.Println(u.ID) fmt.Println(u.SS) // Output: // foo // a123,456 }</code></pre>package main import ( "fmt" "github.com/leodido/go-urn" ) func main() { var uid = "URN:foo:a123,456" // Parse the input string as a RFC 2141 URN only u, ok := urn.Parse([]byte(uid)) if !ok { panic("error parsing urn") } fmt.Println(u.ID) fmt.Println(u.SS) // Output: // foo // a123,456 }</code></pre>package main import ( "fmt" "github.com/leodido/go-urn" ) func main() { input := "urn:ietf:params:scim:api:messages:2.0:ListResponse" // Parsing the input string as a RFC 7643 SCIM URN u, ok := urn.Parse([]byte(input), urn.WithParsingMode(urn.RFC7643Only)) if !ok { panic("error parsing urn") } fmt.Println(u.IsSCIM()) scim := u.SCIM() fmt.Println(scim.Type.String()) fmt.Println(scim.Name) fmt.Println(scim.Other) // Output: // true // api // messages // 2.0:ListResponse }</code></pre>

License §</a> </h2>
Apache License 2.0</a>. Project attribution in NOTICE</a>, per Apache 2.0 §4(d).</p>

structcli

go-conventionalcommits

Docs §</a> </h2>
The parser/docs</a> directory contains `.dot</code> and .png</code> files representing the finite-state machines (FSMs) implementing the parser.</p>`

Build §</a> </h2>
To build this Go library locally just run:</p>
`make</span></span></code></pre> You'd need Ragel 6.10 to be present into your machine.</p>[1]</a>: Intel Core i7-8850H CPU @ 2.60GHz</li> [2]</a>: https://en.wikipedia.org/wiki/nanosecond</a></li> </ul>`

kubectl-trace

Architecture §</a> </h2>
See architecture.md</a></p>

More bpftrace programs §</a> </h3>
Need more programs? Look here</a>.</p>

go-syslog

Docs §</a> </h2>
The docs</a> directory contains `.dot</code> files representing the finite-state machines (FSMs) implementing the syslog parsers and transports.</p>`

go-urn

leodido.dev - Go

kfeatures

Stability§</a> </h2>
Pre-1.0. The public API may change between minor versions; breaking changes are called out explicitly in CHANGELOG.md</a>. The `FromELF</code> contract (signature, determinism, fail-closed semantics) is frozen; seeCONTRIBUTING.md</a>.</p>`

leodido.dev - Go

kfeatures

Stability§</a> </h2> Pre-1.0. The public API may change between minor versions; breaking changes are called out explicitly in CHANGELOG.md</a>. The FromELF</code> contract (signature, determinism, fail-closed semantics) is frozen; see CONTRIBUTING.md</a>.</p>

structcli

go-conventionalcommits

Types§</a> </h3> This library provides support for different types sets:</p> minimal</strong>: fix, feat</li> conventional</strong>: build, ci, chore, docs, feat, fix, perf, refactor, revert, style, test</li>

kubectl-trace

go-syslog

go-urn

Stability§</a> </h2>
Pre-1.0. The public API may change between minor versions; breaking changes are called out explicitly in CHANGELOG.md</a>. The `FromELF</code> contract (signature, determinism, fail-closed semantics) is frozen; seeCONTRIBUTING.md</a>.</p>`