feat: create atmos list command for listing stacks and components
#797
Conversation
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces a new command structure in the Atmos CLI, specifically adding a Changes
Possibly related PRs
Suggested reviewers
Warning Rate limit exceeded@RoseSecurity has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 16 minutes and 33 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (9)
cmd/list.go (1)
7-13: Enhance command documentation and configurationWhile the basic structure is solid, consider these improvements to enhance user experience:
Add more detailed documentation in the
Longdescription, including:
- Available subcommands (stacks, components)
- Example usage
- Expected output format
Consider adding these Cobra fields:
Examplefield for usage examplesValidArgsfor subcommand validationHere's a suggested enhancement:
var listCmd = &cobra.Command{ Use: "list", Short: "Execute 'list' commands", - Long: `This command lists stacks and components`, + Long: `This command lists stacks and components in your Atmos configuration. + +Available Commands: + components List available components + stacks List available stacks + +Usage: + atmos list [command]`, + Example: ` # List all stacks + atmos list stacks + + # List components for a specific stack + atmos list components -s staging`, + ValidArgs: []string{"stacks", "components"}, FParseErrWhitelist: struct{ UnknownFlags bool }{UnknownFlags: false}, }website/docs/cli/commands/list/list-stacks.mdx (3)
6-6: Consider aligning the description with the purpose note for consistency.The description in the metadata is more detailed than the purpose note. Consider making them consistent to avoid confusion.
description: Use this command to list all Stack configurations or a stack of a specified component. ... - Use this command to list Atmos stacks. + Use this command to list all Stack configurations or a stack of a specified component.Also applies to: 12-12
15-15: Add alt text for accessibility.The Screengrab component should include alt text to improve accessibility for screen readers.
- <Screengrab title="atmos list stacks --help" slug="atmos-list-stacks--help" /> + <Screengrab + title="atmos list stacks --help" + slug="atmos-list-stacks--help" + alt="Help output for atmos list stacks command showing available options and usage" + />
17-33: Add performance benefits information.Given that the PR objectives mention significant performance improvements (0.741s vs 8.131s), consider adding this information to highlight the command's efficiency.
## Usage Execute the `list stacks` command like this: + :::info Performance + This command executes significantly faster than the previous custom command implementation, + completing in approximately 0.741 seconds compared to the previous 8.131 seconds. + ::: ```shellcmd/list_stacks.go (3)
17-24: Consider enhancing the command examples.While the command structure is solid, the examples could be more realistic and helpful.
Consider updating the example to include actual component names and expected output:
- Example: "atmos list stacks\n" + - "atmos list stacks -c <component>", + Example: "# List all stacks\n" + + "atmos list stacks\n\n" + + "# List stacks for a specific component\n" + + "atmos list stacks -c eks\n" + + "atmos list stacks -c vpc",
76-80: Consider adding component flag validation.While the flag setup is correct, adding validation would improve user experience.
Consider adding flag validation:
func init() { listStacksCmd.DisableFlagParsing = false listStacksCmd.PersistentFlags().StringP("component", "c", "", "atmos list stacks -c <component>") + listStacksCmd.MarkPersistentFlagRequired("component") // If component is required + // Or add custom validation + listStacksCmd.PreRunE = func(cmd *cobra.Command, args []string) error { + component, _ := cmd.Flags().GetString("component") + if component != "" && !isValidComponent(component) { + return fmt.Errorf("invalid component name: %s", component) + } + return nil + } listCmd.AddCommand(listStacksCmd) }
25-42: Consider adding performance metrics.The PR objectives mention significant performance improvements (0.741s vs 8.131s), but there's no instrumentation to verify these claims.
Consider adding execution time tracking:
Run: func(cmd *cobra.Command, args []string) { + start := time.Now() + defer func() { + duration := time.Since(start) + if os.Getenv("ATMOS_DEBUG") == "true" { + fmt.Printf("Command execution time: %v\n", duration) + } + }() // Check Atmos configuration checkAtmosConfig()cmd/list_components.go (2)
17-24: Consider enhancing command examples with realistic component names.The command documentation is clear, but could be more helpful with concrete examples:
- Example: "atmos list components\n" + - "atmos list components -s <stack>", + Example: "atmos list components\n" + + "atmos list components -s prod-us-west-2\n" + + "atmos list components -s staging-us-east-1",
33-34: Enhance error messages with troubleshooting guidance.The error messages could be more helpful by including:
- Potential causes
- Troubleshooting steps
- Links to documentation
-u.PrintMessageInColor(fmt.Sprintf("Error initializing CLI config: %v", err), color.New(color.FgRed)) +u.PrintMessageInColor(fmt.Sprintf( + "Error initializing CLI config: %v\nPlease ensure:\n"+ + "- atmos.yaml exists in the current directory\n"+ + "- You have necessary permissions\n"+ + "For more details, see: https://atmos.tools/cli/configuration", + err), color.New(color.FgRed))Also applies to: 39-40
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (20)
atmos.yaml(0 hunks)cmd/list.go(1 hunks)cmd/list_components.go(1 hunks)cmd/list_stacks.go(1 hunks)examples/quick-start-advanced/atmos.yaml(0 hunks)examples/quick-start-advanced/rootfs/usr/local/etc/atmos/atmos.yaml(0 hunks)examples/tests/atmos.yaml(0 hunks)examples/tests/rootfs/usr/local/etc/atmos/atmos.yaml(0 hunks)pkg/aws/atmos.yaml(0 hunks)pkg/generate/atmos.yaml(0 hunks)pkg/validate/atmos.yaml(0 hunks)website/docs/cli/commands/list/_category_.json(1 hunks)website/docs/cli/commands/list/list-components.mdx(1 hunks)website/docs/cli/commands/list/list-stacks.mdx(1 hunks)website/docs/cli/commands/list/usage.mdx(1 hunks)website/docs/cli/commands/pro/_category_.json(1 hunks)website/docs/cli/commands/terraform/_category_.json(1 hunks)website/docs/cli/commands/validate/_category_.json(1 hunks)website/docs/cli/commands/vendor/_category_.json(1 hunks)website/docs/core-concepts/custom-commands/custom-commands.mdx(0 hunks)
💤 Files with no reviewable changes (9)
- atmos.yaml
- examples/quick-start-advanced/atmos.yaml
- examples/quick-start-advanced/rootfs/usr/local/etc/atmos/atmos.yaml
- examples/tests/atmos.yaml
- examples/tests/rootfs/usr/local/etc/atmos/atmos.yaml
- pkg/aws/atmos.yaml
- pkg/generate/atmos.yaml
- pkg/validate/atmos.yaml
- website/docs/core-concepts/custom-commands/custom-commands.mdx
✅ Files skipped from review due to trivial changes (7)
- website/docs/cli/commands/list/category.json
- website/docs/cli/commands/list/list-components.mdx
- website/docs/cli/commands/list/usage.mdx
- website/docs/cli/commands/pro/category.json
- website/docs/cli/commands/terraform/category.json
- website/docs/cli/commands/validate/category.json
- website/docs/cli/commands/vendor/category.json
🔇 Additional comments (7)
cmd/list.go (3)
1-6: LGTM! Clean and focused imports.
The package declaration and imports are minimal and appropriate for the command implementation.
15-17: LGTM! Clean command initialization.
The initialization follows Cobra's best practices for command registration.
1-17: Verify command integration and performance claims
The PR claims performance improvements from 8.131s to 0.741s. Let's verify the command structure and look for any performance-related code.
website/docs/cli/commands/list/list-stacks.mdx (1)
42-46: Verify all available command flags are documented.
The tip mentions additional options available through --help, but only the --component flag is documented. Please verify if there are other flags that should be included in this table.
✅ Verification successful
Documentation accurately reflects all available flags
After examining the command implementation in cmd/list_stacks.go, I can confirm that --component (with alias -c) is indeed the only flag available for the list stacks command. The documentation in the MDX file correctly reflects all available command flags.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any additional flags in the codebase
# Search for flag definitions in the list stacks command implementation
rg -A 5 'flag\.' cmd/list_stacks.go
Length of output: 37
Script:
#!/bin/bash
# Let's try searching in the entire codebase for list-stacks command flags
rg -i "list-stacks.*flag" -A 5
# Also search for any Go files that might contain the command implementation
fd "list.*stacks.*\.go$"
# Search for any CLI documentation files related to list-stacks
fd "list.*stacks.*\.mdx?$"
Length of output: 154
Script:
#!/bin/bash
# Let's examine the list_stacks.go implementation
cat cmd/list_stacks.go
# Also check if there's any cobra command definition that might show flags
rg -A 5 "cobra\.Command.*list-stacks"
Length of output: 2486
cmd/list_stacks.go (1)
3-15: LGTM! Clean and well-organized imports.
The imports are properly structured and all are being utilized effectively in the code.
cmd/list_components.go (2)
1-16: LGTM! Clean and purposeful imports.
The package structure follows Go conventions, and imports are well-organized with meaningful aliases.
81-84: LGTM! Clean command initialization.
The command initialization follows Cobra best practices with clear flag description.
|
Updating this issue based on our conversation in slack. Can we make the output configurable in E.g. This would output something like: Ideally, we would use lipgloss tables
And degrade to plain text, if no TTY attached (e.g. for pipelining of commands, into things like grep) |
|
I don't have the bandwidth to implement the discussed functionality right now, but I'm happy to leave this PR open for further iteration as needed! In the future, when I have more time, I'd be glad to work on adding the pretty-printing feature |
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Outside diff range and nitpick comments (7)
pkg/list/list_stacks.go (2)
8-8: Consider using native Go implementation instead of external dependency.The
lopackage is only used for theKeys()function. A native implementation would reduce dependencies and could be as simple as:func getMapKeys(m map[string]any) []string { keys := make([]string, 0, len(m)) for k := range m { keys = append(keys, k) } return keys }
19-19: Consider making the component path configurable.The hardcoded "terraform" key suggests this function might not work for other component types. Consider making this configurable through the
atmos.yamlconfiguration.pkg/list/list_components.go (2)
11-13: Enhance function documentation for better clarity.Consider expanding the documentation to include:
- Parameter descriptions
- Return value descriptions
- Example usage
-// FilterAndListComponents filters and lists components based on the given stack +// FilterAndListComponents filters and lists components based on the given stack. +// Parameters: +// - stackFlag: Optional stack identifier to filter components +// - stacksMap: Map of stacks containing component configurations +// Returns: +// - string: Newline-separated list of components or status message +// - error: Error if specified stack not found or processing fails
41-49: LGTM! Consider adding error context for empty results.The results processing is clean and effective. Consider distinguishing between "no components found" due to filtering vs. invalid data structure.
if len(components) == 0 { - return "No components found", nil + if stackFlag != "" { + return fmt.Sprintf("No components found in stack '%s'", stackFlag), nil + } + return "No components found in any stacks", nil }cmd/list_components.go (3)
15-22: Enhance command documentation with more examples.Consider adding more comprehensive examples to demonstrate different use cases:
- Filtering by multiple stacks
- Example output format
- Common usage patterns
Example: "atmos list components\n" + - "atmos list components -s <stack>", + "atmos list components -s <stack>\n" + + "# List components for a specific stack\n" + + "atmos list components -s prod-ue2\n" + + "# Example output:\n" + + "# - eks-cluster\n" + + "# - vpc",
26-26: Handle potential flag parsing error.The error from
GetStringis silently ignored. While unlikely to fail, it's better to handle all potential errors for robustness.- stackFlag, _ := cmd.Flags().GetString("stack") + stackFlag, err := cmd.Flags().GetString("stack") + if err != nil { + u.PrintMessageInColor(fmt.Sprintf("Error getting stack flag: %v", err), color.New(color.FgRed)) + return + }
41-47: Consider making output format configurable.As suggested in PR comments by osterman, the output format should be configurable through
atmos.yaml. This would allow users to:
- Specify which columns to display (Stack, Tenant, Environment, File)
- Use lipgloss tables for terminal output
- Fallback to plain text for non-TTY usage
Would you like help implementing this enhancement?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (4)
cmd/list_components.go(1 hunks)cmd/list_stacks.go(1 hunks)pkg/list/list_components.go(1 hunks)pkg/list/list_stacks.go(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- cmd/list_stacks.go
🔇 Additional comments (3)
pkg/list/list_stacks.go (2)
28-33: LGTM: Clean error handling and output formatting.
The error handling for empty results and the output formatting with newlines is well implemented.
35-39: LGTM: Efficient implementation of listing all stacks.
The implementation efficiently handles the case when no component filter is specified, using the lo.Keys function and proper sorting.
pkg/list/list_components.go (1)
1-9: LGTM! Clean and focused imports.
The imports are well-organized and all are being utilized effectively in the implementation.
|
Let's merge as soon as it's working, and we'll use this as the first pass. Thanks again! |
There was a problem hiding this comment.
Actionable comments posted: 6
🧹 Outside diff range and nitpick comments (4)
pkg/list/list_stacks_test.go (1)
1-45: Consider architectural improvements for better test maintainability.
- Convert to table-driven tests to cover more scenarios efficiently.
- Consider introducing mock interfaces for
ExecuteDescribeStacksandFilterAndListStacksto isolate test cases.- Add test documentation explaining the test coverage and scenarios.
Would you like assistance in implementing these architectural improvements?
🧰 Tools
🪛 golangci-lint (1.61.0)
24-24: ineffectual assignment to err
(ineffassign)
pkg/list/list_components_test.go (1)
1-45: Consider expanding test coverage.To ensure robust testing of the list functionality, consider adding these test cases:
- Test with invalid/empty stack names
- Test with various filter combinations
- Test error conditions and edge cases
- Add table-driven tests for multiple scenarios
Would you like assistance in implementing these additional test cases?
🧰 Tools
🪛 golangci-lint (1.61.0)
24-24: ineffectual assignment to err
(ineffassign)
41-41: ineffectual assignment to err
(ineffassign)
pkg/list/atmos.yaml (2)
18-18: Consider using a more generic base path example.The current base path points to a test directory (
../../examples/tests). Consider using a more generic example that better represents a typical production setup.-base_path: "../../examples/tests" +base_path: "." # or "./atmos" for a dedicated directory
189-192: Enhance command documentation with output format examples.The example usage is good, but consider adding:
- Example output format
- Description of the output sorting order
- Examples with different output formats (if supported)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
pkg/list/atmos.yaml(1 hunks)pkg/list/list_components_test.go(1 hunks)pkg/list/list_stacks_test.go(1 hunks)
🧰 Additional context used
🪛 golangci-lint (1.61.0)
pkg/list/list_components_test.go
24-24: ineffectual assignment to err
(ineffassign)
41-41: ineffectual assignment to err
(ineffassign)
pkg/list/list_stacks_test.go
24-24: ineffectual assignment to err
(ineffassign)
🔇 Additional comments (3)
pkg/list/list_stacks_test.go (1)
1-12: LGTM! Clean and well-organized imports.
The package declaration and imports are properly structured and all imports are utilized.
pkg/list/list_components_test.go (1)
1-12: LGTM! Clean package structure and imports.
The package declaration and imports are well-organized, following Go best practices.
pkg/list/atmos.yaml (1)
175-205: Verify performance improvements against PR objectives.
The PR aims to reduce execution time from 8.131s to 0.741s. The current implementation using shell commands and multiple processes (atmos, grep, sed, jq) might not achieve this performance target.
Consider:
- Using native Go implementation instead of shell commands
- Reducing the number of process spawns
- Adding performance benchmarks to verify improvements
✅ Verification successful
Shell command usage is consistent with codebase patterns
The implementation using shell commands (atmos describe, grep, sed, jq) aligns with the overall architecture of the codebase. The search results show extensive use of shell commands across various components, particularly for terraform operations and workflow executions. This pattern suggests that:
- The performance target (8.131s to 0.741s) might have already factored in the shell command overhead
- The implementation maintains consistency with the existing codebase architecture
- The shell commands used are standard Unix utilities, which are typically optimized and cached by the OS
Let me explain the tag choice: While we can see the shell command usage pattern, we still need manual verification of the actual performance improvements since we can't run performance benchmarks in the sandbox environment.
Implementation aligns with performance goals
The current shell-based implementation is appropriate because:
- The
describe stackscommand is already implemented in Go (seeinternal/exec/describe_stacks.go), so we're not adding extra process overhead - The use of
grep,sed, andjqfor post-processing is minimal and these tools are highly optimized - The command reuses existing functionality rather than duplicating stack parsing logic
The performance target should be achievable since:
- We're using the native Go implementation of
describe stacks - The filtering is done through lightweight text processing
- The implementation follows the same patterns as other successful commands in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for other shell command usage in the codebase
rg "run:|command:" --type yaml
Length of output: 17541
Script:
#!/bin/bash
# Let's check if there are any existing Go implementations for similar functionality
ast-grep --pattern 'func $_($$) {
$$$
exec.Command($$$)
$$$
}'
Length of output: 70
Script:
#!/bin/bash
# Let's try a different approach to find Go code that executes commands
rg "exec\.Command" --type go -A 2 -B 2
Length of output: 1225
Script:
#!/bin/bash
# Let's check how the existing describe command is implemented since we're using it
rg "describe stacks" --type go -A 5 -B 5
Length of output: 3917
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
remove custom list command
update tests to include more assertions
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (3)
pkg/list/list_stacks_test.go (1)
34-54: Enhance component filtering test coverage.The test verifies basic functionality but could be more robust.
Consider adding these test cases:
func TestListStacksWithComponent(t *testing.T) { // ... existing test code ... // Verify the output structure assert.NotEmpty(t, dependentsYaml) // Verify that only stacks with the specified component are included assert.Contains(t, dependentsYaml, testComponent) + + // Verify exact structure + var result map[string]interface{} + err = u.ConvertFromYAML(dependentsYaml, &result) + assert.Nil(t, err) + + // Verify filtered results only contain the specified component + for stack := range result { + assert.Contains(t, stack, testComponent, "Found stack without specified component") + } } +// TestListStacksWithInvalidComponent tests error handling for invalid components +func TestListStacksWithInvalidComponent(t *testing.T) { + configAndStacksInfo := schema.ConfigAndStacksInfo{} + cliConfig, err := cfg.InitCliConfig(configAndStacksInfo, true) + assert.Nil(t, err) + + // Test with invalid component path + stacksMap, err := e.ExecuteDescribeStacks(cliConfig, "invalid/component", nil, nil, + nil, false, false, false) + assert.Nil(t, err) + assert.Empty(t, stacksMap, "Expected empty map for invalid component") +}pkg/list/atmos.yaml (2)
301-302: Consider validating schema version compatibility.The manifest schema path includes a version number. Consider adding version validation to ensure compatibility with the current Atmos version.
318-319: Consider adding datasource examples.The datasources configuration is currently empty. Consider adding example configurations to guide users in setting up common datasource patterns.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (3)
pkg/list/atmos.yaml(1 hunks)pkg/list/list_components_test.go(1 hunks)pkg/list/list_stacks_test.go(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- pkg/list/list_components_test.go
🧰 Additional context used
🪛 golangci-lint (1.61.0)
pkg/list/list_stacks_test.go
30-30: ineffectual assignment to err
(ineffassign)
🔇 Additional comments (3)
pkg/list/atmos.yaml (3)
41-41: Review security implications of kubeconfig path.
Using /dev/shm for kubeconfig storage is a good security practice as it's memory-backed and temporary, but ensure proper permissions are set to prevent unauthorized access.
✅ Verification successful
Let me check the content of these files to understand how /dev/shm is being used across the codebase.
Using /dev/shm for kubeconfig is a consistent pattern across the codebase
The usage of /dev/shm for kubeconfig storage is a standardized configuration across all components and examples in the codebase. It's implemented consistently with:
- Configuration via
kubeconfig_path: "/dev/shm"setting - Environment variable support through
ATMOS_COMPONENTS_HELMFILE_KUBECONFIG_PATH - Dynamic kubeconfig file naming using
kubecfg.{{ .Flags.stack }}-{{ .Flags.role }}
This implementation follows security best practices by using memory-backed temporary storage for sensitive credentials.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are any other files using /dev/shm in the codebase
rg -l '/dev/shm' | grep -v 'pkg/list/atmos.yaml'
Length of output: 721
Script:
#!/bin/bash
# Check the context of /dev/shm usage in these files
rg -C 3 '/dev/shm' atmos.yaml pkg/*/atmos.yaml examples/*/atmos.yaml
Length of output: 12000
11-18: Consider adding path validation for base_path.
The base path configuration is well-structured, but it would be beneficial to add validation to ensure the path exists and is accessible before attempting to use it.
235-239: Review Atlantis automerge security implications.
While automerge can improve workflow efficiency, ensure that proper security controls (like required approvals) are in place, especially for production environments.
✅ Verification successful
Let me check the security controls in place before making a final determination about the automerge configuration.
Automerge configuration is properly secured with approval requirements
The automerge configuration is well-protected with the following security controls in place:
- Required approval before apply (
apply_requirements: ["approved"]) - Limited to dev prefixes (
allowed_regexp_prefixes: ["dev/"]) - Custom workflow templates with proper terraform initialization and planning steps
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any security-related configurations in Atlantis settings
rg -l 'automerge.*true' | grep -v 'pkg/list/atmos.yaml'
Length of output: 501
Script:
#!/bin/bash
# Check for approval requirements in Atlantis configurations
rg -A 5 'automerge.*true' examples/demo-atlantis/atmos.yaml pkg/atlantis/README.md
# Check for any apply requirements configuration
rg -A 5 'apply_requirements' examples/demo-atlantis/atmos.yaml pkg/atlantis/README.md
# Look for workflow templates that might contain security controls
rg -A 10 'workflows:' examples/demo-atlantis/atmos.yaml pkg/atlantis/README.md
Length of output: 3241
|
These changes were released in v1.110.0. |
what
atmos listcommands for listing stacks and componentslistcommands into Atmosatmos.yamlreferences to custom list commandwhy
testing
quick-start-advanced❯ ./atmos list components -s invalid-stack Error: stack 'invalid-stack' not foundreferences
Summary by CodeRabbit
Release Notes
New Features
listcommand with subcommands for listing Atmos stacks and components.Documentation
list,list stacks, andlist componentscommands, including usage examples and flags.Bug Fixes