Version Files
version.files declares which files carry managed versions. atmos version track apply rewrites those files from the lock file, and verify fails when they drift.
Configuration
When version.files is empty, managers with default paths run over those defaults.
Managers
github-actions- Rewrites
uses:refs in workflow files by matchingowner/repopackages. marker- Rewrites version tokens on lines annotated with
atmos:versioncomments. template- Renders
*.tmplsource files to sibling files using the.versioncontext.
Updating Dockerfiles
Annotate the line to update with an atmos:version comment. The marker manager rewrites the version token in place from the lock file, matching entries by name. Given this atmos.yaml:
atmos version track apply prod keeps annotated lines in sync with the locked versions:
- Single Tool
- Multiple Tools
- YAML
- Custom Match Pattern
A file can track more than one tool — each just needs its own marker line:
The same annotation works in any commented format — the manager rewrites whatever token it finds on the marked line, not just Dockerfile ENV statements:
Use match= when the default token detection is ambiguous, for example a version-shaped path segment appearing before the actual version. A trailing comment marks its own line:
A standalone comment on the preceding line marks the next non-blank, non-comment line instead:
Updating GitHub Action Workflows
The github-actions manager rewrites uses: refs in workflow files, matching entries by owner/repo package.
- Version Bump
- Pinned to SHA
Add a dependency for the action and register the manager:
atmos version track apply prod rewrites the matching uses: line to the locked version:
Set update.pin: sha to pin third-party actions to their immutable commit SHA instead — Atmos writes the SHA with the human-readable version as a trailing comment, matching the Renovate/Dependabot convention:
Examples
atmos version track apply prod
atmos version track apply prod --check
atmos version track apply prod --manager=github-actions