Contribute
The most useful contribution often isn’t code. It’s a scenario or a fault nobody has written yet, based on a failure you have actually had to fix.
Four ways in
- No Go required
Author content
Scenarios, faults, learning paths and challenges are YAML plus shell scripts. The Go code runs and grades them but never contains them, so you don't need to know Go.
Your first scenario - Go 1.25+
Fix code
labctl is a Go module under src/: thin cobra commands over a durable run engine with SQLite storage, and a React dashboard embedded in the binary.
How it works - Any level
Strengthen the tests
Every change ships with tests: Go unit, shell (bats with kubectl stubbed), UI component (vitest) and end-to-end (Playwright). Coverage is gated in CI.
Testing guide - Any level
Report what broke
It's an early release and it moves fast. A report with your labctl doctor output and the command that failed is the most useful kind.
Open an issue
From clone to running tests
Contributors clone main and build labctl from source, which needs Go 1.25+ and Node 22+. People using the lab don't need either.
Build it
git clone https://github.com/sagar2395/snowopslabs.git
cd snowopslabs
make cli-build # bin/labctl, UI embedded
make cli-install # install it and record this clone as the labProve it still works
make test # Go unit + shell, race, coverage gates
make test-ui # vitest component tests
make test-e2e # playwright journeys
make lint # every static-analysis gate
make validate # all content is well-formedCommits are signed off under the DCO, and changes to the engine, the Go SDK or the scenario schema start with a short RFC. The contributing guide has the full PR bar.
The golden rules
Three principles that settle most review conversations before they start.
Everything is verifiable
Checks are the core primitive. A scenario without checks is a blog post.
Declarative content, orchestrating code
If it can be YAML, it is YAML. Go never encodes the content itself.
Every layer, every change
Tests at every layer the change touches, in the same pull request.
The catalog has 6 faults. Production has thousands.
If you have debugged a failure that isn’t in the library, like a certificate that expired at the worst moment, a DNS change that took out half a namespace, or a CNI upgrade that went sideways, that is the contribution the project wants most. Faults need to be realistic and reversible. Everything else can be worked out in review.