Skip to main content

Atmos Now Builds Atmos

· 3 min read
Erik Osterman
Erik Osterman
Founder @ Cloud Posse

Atmos now builds itself through a first-class Atmos command:

atmos build --target linux

We replaced the old Make-based build and CI entrypoints with Atmos custom commands to improve the developer experience and dogfood our own workflow engine. Build and test workflows now expose the flags developers actually care about, such as the target platform, while Atmos owns the shell details, cross-compilation wiring, output paths, and CI glue behind the command.

What Changed​

The repository's development commands now live in .atmos.d/ command groups instead of Make targets. The root atmos.yaml stays focused on project configuration, while the command surface is split by concern:

  • atmos build ... for dependencies, binaries, versions, and docs generation.
  • atmos test plus mode flags for short, acceptance, coverage, and race-test workflows.
  • atmos lint ... for changed-file linting, custom lintroller rules, go.mod checks, and link checks.
  • atmos check ..., atmos format ..., and atmos cache ... for repository maintenance workflows.
  • atmos screengrabs ... for website screengrab generation.

Makefiles remain only as migration guards. If someone runs an old target, the Makefile exits and points them to the Atmos command that replaced it.

A Cleaner Command Surface​

The result is intentionally plain. The repository now has command groups that read like the workflows contributors actually run:

atmos build deps
atmos build --target linux
atmos test acceptance --cover
atmos lint --changed
atmos screengrabs all

This keeps the developer contract narrow. The command can grow flags like --target without forcing every contributor or CI job to understand the lower-level build minutia. Atmos handles the parsing, defaults, and orchestration once, and every caller gets the same behavior.

Why It Matters​

This is dogfooding in the useful sense: Atmos exercises its own custom command engine for the daily loops that maintain Atmos. That gives contributors one command vocabulary locally and in CI, and it gives us immediate feedback when custom commands need to become better.

It also removes a layer. CI now calls grouped Atmos commands such as atmos build deps, atmos build --target linux, and atmos test acceptance --cover. The screengrab workflow calls atmos screengrabs all. The install script has its own Linux, macOS, and Windows smoke test, so the installer path gets exercised directly too.

Try the Pattern​

If you are maintaining a repo with an aging Makefile, .atmos.d/ is a good place to split the command surface by concern. Keep project configuration in atmos.yaml; keep operational commands in grouped files such as .atmos.d/build.yaml, .atmos.d/test.yaml, and .atmos.d/lint.yaml.

For the general command schema, see the custom commands documentation. For a smaller standalone example, browse the custom commands example.