Implement custom secrets masking patterns and fix output routing @osterman (#1972)
## what- Added
registerCustomMaskPatterns()to load user-defined patterns and literals fromatmos.yamlconfig - Updated masker to support custom replacement strings from config settings
- Fixed all output paths to route through io layer for automatic secret masking
- Created
examples/secrets-masking/directory demonstrating the feature with test configs and components
why
Secrets matching user-defined patterns are now automatically masked across all CLI output (terraform, logs, auth commands, docs, help text, etc.), preventing accidental exposure while maintaining the ability to customize masking behavior per environment.
references
Implements custom pattern/literal loading for the secrets masking feature that was already configured in the schema but not being loaded or applied.
Summary by CodeRabbit
-
New Features
- Global secrets masking: configurable enable/disable, custom regex patterns, literal values, and configurable replacement text; applied across CLI, logs, docs and tooling.
- Added an Example Creator agent to generate self-contained demo examples and mocks.
-
Documentation
- Expanded secrets-masking docs, new agent guide, embedded examples, updated examples list, and a blog post announcing custom masking.
-
Tests
- New/updated test cases and snapshots to reflect masking behavior.
-
Chores
- Visible telemetry notice with opt-out instructions.
✏️ Tip: You can customize this high-level summary in your review settings.
fix: Skip CODEOWNERS validation when file not modified @osterman (#2016)
## what- Added
tj-actions/changed-filesstep to detect if.github/CODEOWNERSwas modified in the PR - Only run CODEOWNERS validation checks when the file actually changed or on manual
workflow_dispatchtriggers - Prevents unnecessary validation overhead for PRs that don't touch the CODEOWNERS file
why
- The CODEOWNERS validation should only run when the file is actually modified
- This reduces CI overhead and prevents friction for unrelated PRs
- Always allow manual validation via
workflow_dispatchfor verification purposes
references
- Uses
tj-actions/changed-files@v45- a widely-used, well-maintained action for detecting changed files
🚀 Enhancements
fix: Audit and fix broken links in README @osterman (#2013)
## what- Fixed 15 broken
/core-concepts/*links in README that returned 404 errors - Added 5 missing redirects to docusaurus.config.js for backward compatibility
- Uncommented workflows redirect with corrected target URL
- Created GitHub Action workflow (.github/workflows/link-check.yml) to automatically check .md files for broken links using lychee
why
GitHub reported 404 errors for several README links pointing to moved documentation pages. Adding redirects provides backward compatibility for external references, and the new link checker prevents future broken link regressions.
references
Related to: https://github.com/cloudposse/atmos/issues (README broken links audit)
Summary by CodeRabbit
-
New Features
- Added automated link validation (CI workflow + local target) to catch broken Markdown links.
-
Documentation
- Reorganized and updated many documentation links to new site structure for consistency.
- Corrected external references to third-party docs and adjusted cross‑references across guides and examples.
- Minor content alignments and added a Use Case bullet about service catalogs/landing zones.
-
Chores
- Added link-check configuration and a Makefile target to run the checker locally.
✏️ Tip: You can customize this high-level summary in your review settings.
fix: Use toolchain.GetInstallPath() for PATH construction @osterman (#2015)
## what- Ensures PATH points to where tools are actually installed (XDG path by default) instead of hardcoded
.toolsdirectory - Fixes issue where custom commands and workflows would use system-installed tools instead of toolchain-managed versions
- Adds test to reproduce and validate the PATH mismatch bug
why
Tools are installed via toolchain.GetInstallPath() (defaults to ~/.local/share/atmos/toolchain), but BuildToolchainPATH() and NewInstaller() were using a hardcoded .tools default. This caused PATH to point to the wrong directory, making system-installed tools (like brew-installed helm) take precedence over the Atmos-managed versions.
references
Resolves issue where users had to work around the bug using atmos toolchain exec helm/helm -- instead of calling helm directly in custom commands.
Summary by CodeRabbit
-
Bug Fixes
- Enhanced tool binary path resolution to consistently use the centralized toolchain installation path instead of hard-coded defaults, while maintaining backward compatibility with custom paths when configured
-
Tests
- Added test coverage to verify PATH construction correctly includes the actual toolchain installation path for tool binaries
✏️ Tip: You can customize this high-level summary in your review settings.
fix: Windows toolchain installation issues @aknysh (#2012)
## what- Fix Windows toolchain installation failures where binaries were installed without
.exeextension - Fix GitHub release download URLs to include
.exefor raw binaries on Windows (following Aqua behavior) - Fix archive extraction for tools like helm that have
.exebinaries inside archives - Fix hint message to show PowerShell
Invoke-Expressionsyntax instead of Unixevalon Windows - Improve
.atmos.ddirectory detection to differentiate permission errors from not-found errors - Extend archive extension detection to include
.tar.xz,.tar.bz2,.7z, and other formats - Add integration tests for Windows toolchain functionality
- Update CLI documentation with PowerShell examples
why
Users reported multiple issues when using atmos toolchain install on Windows:
- Binary without
.exeextension - Installing tools like terraform resulted in binaries without.exeextension, causingterraform --versionto hang indefinitely - Download URL missing
.exe- Tools like jq that have standalone Windows binaries (e.g.,jq-windows-amd64.exe) failed to download because the URL was constructed without.exe - Archive extraction failures - Tools like helm that ship as archives (
.tar.gz,.zip) failed because the extractor looked forwindows-amd64/helminstead ofwindows-amd64/helm.exe - Wrong shell hint - The hint message showed Unix
eval $(...)syntax instead of PowerShellInvoke-Expressionsyntax
Architecture
Centralized Windows Extension Handling
Following Aqua's Windows support approach, Windows executables need the .exe extension to be found by os/exec.LookPath. We use a single centralized function:
// EnsureWindowsExeExtension appends .exe to the binary name on Windows if not present.
func EnsureWindowsExeExtension(binaryName string) string {
if runtime.GOOS == "windows" && \!strings.HasSuffix(strings.ToLower(binaryName), ".exe") {
return binaryName + ".exe"
}
return binaryName
}Download URL Handling by Tool Type
| Tool Type | Download URL .exe Handling
|
|---|---|
github_release
| Automatic: Adds .exe on Windows for raw binaries (assets without archive extensions like .tar.gz, .zip)
|
http
| Manual: The asset template must include .exe in the URL if needed
|
This matches Aqua's behavior where .exe is added to the download URL upfront during URL construction, not as a fallback after a 404 error.
Archive Extension Detection
Extended to recognize additional formats to avoid incorrectly appending .exe to archive URLs:
var archiveExtensions = []string{
".tar.gz", ".tgz", ".zip", ".gz",
".tar.xz", ".txz", ".tar.bz2", ".tbz", ".tbz2",
".bz2", ".xz", ".7z", ".tar", ".pkg",
}Archive Extraction
When extracting from archives, the .exe fallback only runs on Windows (not on Unix) to avoid masking wrong-asset errors.
Fixes Applied
| File | Fix |
|---|---|
toolchain/installer/installer.go
| Added EnsureWindowsExeExtension() centralized function
|
toolchain/installer/asset.go
| Adds .exe to GitHub release URLs for raw binaries on Windows; extended archive detection
|
toolchain/installer/extract.go
| Uses centralized function; .exe fallback only on Windows
|
toolchain/install_helpers.go
| Platform-aware hint message for PowerShell |
pkg/config/load.go
| Differentiate stat errors from not-found for .atmos.d directories
|
Test Results (Windows)
All integration tests pass on Windows:
--- PASS: TestToolchainCustomCommands_InstallAllTools (14.04s)
--- PASS: TestToolchainCustomCommands_ToolsExecutable (12.33s)
--- PASS: TestToolchainCustomCommands_PathEnvOutput (10.09s)
--- PASS: TestToolchainCustomCommands_WindowsExeExtension (8.91s)
--- PASS: TestToolchainCustomCommands_CustomCommandsLoaded (8.31s)
--- PASS: TestToolchainCustomCommands_ExecuteWithDependencies (14.50s)
PASS
references
- Full documentation:
docs/fixes/windows-atmos-d-and-toolchain-issues.md - Test fixture:
tests/fixtures/scenarios/toolchain-custom-commands - Integration tests:
tests/toolchain_custom_commands_test.go
Summary by CodeRabbit
-
New Features
- Tabbed Bash/Zsh and PowerShell examples for env/shell guidance.
- Custom toolchain commands with dependency-driven tool installation and a Terraform test component.
-
Bug Fixes
- Improved Windows executable handling (.exe normalization for downloads/installs).
- Safer atmos.d/.atmos.d detection with clearer "no directory found" messages and adjusted log levels.
- Platform-aware PATH export hints in installer output.
-
Documentation
- Added Windows toolchain troubleshooting guide; updated CLI docs for cross-platform usage.
-
Tests
- New unit and integration tests covering custom commands, toolchain installs, Windows behaviors, and env handling.
✏️ Tip: You can customize this high-level summary in your review settings.