Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Filter out empty results from describe stacks #764

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

Cerebrovinny
Copy link
Collaborator

@Cerebrovinny Cerebrovinny commented Nov 5, 2024

what

This PR changes the default behavior of atmos describe stacks it filter empty stacks by default unless user pass the flag --include-empty-stacks

why

This was causing stacks with empty results or no components/imports components to be displayed.

Test Results

Screenshot 2024-11-05 at 11 36 39
Screenshot 2024-11-05 at 11 36 53

references

DEV-1880

Summary by CodeRabbit

  • New Features

    • Introduced a new command-line flag --include-empty-stacks to include stacks without components in the output.
    • Enhanced stack processing logic to support filtering based on the new flag.
  • Bug Fixes

    • Improved error handling and messaging for Git reference issues.
  • Tests

    • Added new test cases to validate the behavior of the ExecuteDescribeStacks function with empty stacks.

Copy link
Contributor

coderabbitai bot commented Nov 5, 2024

📝 Walkthrough

Walkthrough

The changes introduce a new boolean flag, --include-empty-stacks, to the describeStacksCmd command, allowing users to include stacks without components in the output. This flag defaults to false. Additionally, the ExecuteDescribeStacks function has been updated across several files to accept this new parameter, modifying how stacks are processed and filtered. Error handling has also been improved in related functions, enhancing feedback during execution.

Changes

File Path Change Summary
cmd/describe_stacks.go Added --include-empty-stacks flag to describeStacksCmd.
internal/exec/atmos.go Updated ExecuteDescribeStacks function call to include an additional boolean parameter.
internal/exec/describe_affected_utils.go Modified executeDescribeAffected to include the new parameter in ExecuteDescribeStacks calls and refined error handling.
internal/exec/describe_dependents.go Updated ExecuteDescribeStacks function call to include an additional boolean parameter.
internal/exec/describe_stacks.go Updated ExecuteDescribeStacksCmd and ExecuteDescribeStacks to process the new includeEmptyStacks parameter.
pkg/describe/describe_stacks.go Modified ExecuteDescribeStacks to include includeEmptyStacks parameter in the function signature.
pkg/describe/describe_stacks_test.go Updated test cases to include the new parameter and added tests for handling empty stacks.

Assessment against linked issues

Objective Addressed Explanation
Filter out empty results from describe stacks (DEV-1880)

Possibly related PRs


📜 Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 7629b93 and 37f64bb.

📒 Files selected for processing (2)
  • internal/exec/describe_stacks.go (8 hunks)
  • pkg/describe/describe_stacks_test.go (9 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • internal/exec/describe_stacks.go
  • pkg/describe/describe_stacks_test.go

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?

❤️ Share
🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

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)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary or @auto-summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai or @auto-title anywhere in the PR title to generate the title automatically.

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Outside diff range and nitpick comments (3)
internal/exec/atmos.go (1)

44-44: Consider improving function parameter readability.

The ExecuteDescribeStacks function now has 8 boolean parameters, which makes it difficult to understand what each flag controls. Consider refactoring using one of these approaches:

  1. Use a configuration struct to group related parameters
  2. Add named parameters using builder pattern

Example refactor using a config struct:

+type DescribeStacksConfig struct {
+    IncludeEmptyStacks bool
+    // ... other boolean flags
+}

-stacksMap, err := ExecuteDescribeStacks(cliConfig, "", nil, nil, nil, false, false, false)
+config := DescribeStacksConfig{
+    IncludeEmptyStacks: false,
+    // ... other flags
+}
+stacksMap, err := ExecuteDescribeStacks(cliConfig, "", nil, nil, nil, config)
internal/exec/describe_stacks.go (2)

289-291: Consider refactoring repeated 'deploy/' logic

The logic for handling 'deploy/' prefixed stack names at lines 289-291 and 481-483 is duplicated. Extracting this into a helper function could improve maintainability.

Also applies to: 481-483


294-295: Refactor duplicate condition for stack entries

Lines 294-295 and 486-487 repeat the condition for creating stack entries. Consider a common function for clarity.

Also applies to: 486-487

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 4098092 and 80bfa6e.

📒 Files selected for processing (5)
  • cmd/describe_stacks.go (1 hunks)
  • internal/exec/atmos.go (1 hunks)
  • internal/exec/describe_affected_utils.go (2 hunks)
  • internal/exec/describe_dependents.go (1 hunks)
  • internal/exec/describe_stacks.go (8 hunks)
🔇 Additional comments (13)
cmd/describe_stacks.go (1)

48-48: Well implemented flag addition, warrior! Let's verify the integration.

The new --include-empty-stacks flag is well-positioned and follows proper command patterns. The default value of false aligns perfectly with our mission to filter out empty stacks by default.

Let's confirm the flag's integration across the codebase:

internal/exec/atmos.go (1)

44-44: LGTM! The change aligns with the PR objectives.

The addition of the includeEmptyStacks parameter (set to false) correctly implements the default behavior of filtering out empty stacks.

internal/exec/describe_dependents.go (1)

81-81: LGTM! Parameter update aligns with feature objectives.

The addition of false as the new parameter to ExecuteDescribeStacks is correct here. Empty stacks wouldn't contain any dependencies, so filtering them out maintains consistency with the new default behavior.

Let's verify the consistent usage of this parameter across the codebase:

✅ Verification successful

Parameter usage is consistent with the implementation

The verification shows that all calls to ExecuteDescribeStacks correctly include the new includeEmptyStacks parameter (set to false by default), and the implementation in internal/exec/describe_stacks.go properly handles this parameter by filtering out empty stacks when it's set to false. The change in describe_dependents.go aligns perfectly with the codebase's behavior.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify consistent parameter usage in ExecuteDescribeStacks calls
# Expected: All calls should include the new boolean parameter

# Search for ExecuteDescribeStacks function calls
rg -A 2 "ExecuteDescribeStacks\(" 

Length of output: 3644


Script:

#!/bin/bash
# Let's check the function signatures to ensure they match the usage
ast-grep --pattern 'func ExecuteDescribeStacks($$$)'

Length of output: 39054

internal/exec/describe_affected_utils.go (2)

447-447: LGTM! Parameters for remote stacks processing are correctly set.

The parameters for processing remote stacks are set appropriately, with the first parameter set to true to differentiate it from the current stacks processing.


411-411: LGTM! Verify parameter order for ExecuteDescribeStacks.

The changes align with the PR objectives to filter out empty stacks. The parameters appear to be in the correct order, but let's verify the usage.

✅ Verification successful

Based on the shell script results, I can now verify the parameter order for ExecuteDescribeStacks. The function signature in internal/exec/describe_stacks.go shows:

func ExecuteDescribeStacks(
    cliConfig schema.CliConfiguration,
    filterByStack string,
    components []string,
    componentTypes []string,
    sections []string,
    ignoreMissingFiles bool,
    processTemplates bool,
    includeEmptyStacks bool,
) (map[string]any, error)

Parameters are correctly ordered in the call. All clear!

The call at line 411 uses false, true, false for the last three boolean parameters, which correctly maps to:

  • ignoreMissingFiles: false
  • processTemplates: true
  • includeEmptyStacks: false
🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify the ExecuteDescribeStacks function signature and usage
# Test: Search for the function declaration and other calls to verify parameter order

# Find the function declaration
ast-grep --pattern 'func ExecuteDescribeStacks($_, $_, $_, $_, $_, $_, $_, $_)'

# Find all function calls to verify consistent usage
rg -A 2 'ExecuteDescribeStacks\('

Length of output: 42008

internal/exec/describe_stacks.go (8)

58-62: Good job retrieving 'include-empty-stacks' flag

The flag is correctly fetched and error-handled.


105-105: Properly passes 'includeEmptyStacks' to function

The parameter is correctly utilized in ExecuteDescribeStacks.


128-128: Updates function signature with new parameter

Including 'includeEmptyStacks' aligns the function with new requirements.


137-137: Initializes 'processedStacks' map

This prevents duplicate stack processing.


149-150: Declares 'context' variable

Prepares for stack context handling.


178-183: Avoids processing stacks multiple times

Using 'processedStacks' ensures each stack is unique.


566-617: Efficiently filters empty and duplicate stacks

The code effectively filters out empty stacks and handles 'deploy/' duplicates.


154-176: ⚠️ Potential issue

Check key consistency for 'imports'

At line 169, accessing stackSection["import"] might be inconsistent with earlier usage of stackSection["imports"]. Ensure the key names match to avoid issues.

Apply this diff to fix the key name:

- if importsSection, ok := stackSection.(map[string]any)["import"].([]any); ok {
+ if importsSection, ok := stackSection.(map[string]any)["imports"].([]any); ok {

Likely invalid or redundant comment.

coderabbitai[bot]
coderabbitai bot previously approved these changes Nov 5, 2024
@osterman
Copy link
Member

osterman commented Nov 5, 2024

@Cerebrovinny
Copy link
Collaborator Author

LGTM, but one test failure: https://github.com/cloudposse/atmos/pull/764/files#file-pkg-describe-describe_stacks-go-L18

yep, sorry working on tests + updating docs for this one

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Outside diff range and nitpick comments (3)
pkg/describe/describe_stacks.go (1)

19-19: HOLD! Let's make this return statement more clear, fellow warrior!

The presence of two consecutive boolean parameters (false and includeEmptyStacks) could lead to confusion in battle. Consider improving readability by using named parameters in the function call.

-return e.ExecuteDescribeStacks(cliConfig, filterByStack, components, componentTypes, sections, ignoreMissingFiles, false, includeEmptyStacks)
+return e.ExecuteDescribeStacks(
+    cliConfig,
+    filterByStack,
+    components,
+    componentTypes,
+    sections,
+    ignoreMissingFiles,
+    includeAllStacks: false,  // Clarify the purpose of this parameter
+    includeEmptyStacks,
+)
pkg/describe/describe_stacks_test.go (2)

19-19: LGTM! Consider enhancing test assertions.

The consistent addition of the includeEmptyStacks parameter (set to false) across all test functions aligns well with the new filtering behavior. However, some test functions could benefit from additional assertions to explicitly verify that no empty stacks are included in the results.

For example, in TestDescribeStacksWithFilter1, consider adding:

for _, stackContent := range stacks {
    if components, ok := stackContent.(map[string]any)["components"].(map[string]any); ok {
        assert.Greater(t, len(components), 0, "Should not contain empty stacks")
    }
}

Also applies to: 35-35, 52-52, 69-69, 86-86, 104-104, 136-136, 163-163


227-245: Enhance type assertion safety in stack validation.

While the validation logic is comprehensive, it could benefit from more robust type assertions and error handling.

Consider this safer implementation:

 for stackName, stackContent := range stacksWithEmpty {
-		if stack, ok := stackContent.(map[string]any); ok {
+		stack, ok := stackContent.(map[string]any)
+		if !ok {
+			t.Errorf("Invalid stack content type for %s", stackName)
+			continue
+		}
+
+		components, ok := stack["components"].(map[string]any)
+		if !ok {
+			t.Errorf("Invalid components type for %s", stackName)
+			continue
+		}
+
+		// Check for completely empty components
+		if len(components) == 0 {
+			emptyStacks = append(emptyStacks, stackName)
+			continue
+		}
+
+		// Check if only terraform exists and is empty
+		if len(components) == 1 {
+			terraformComps, ok := components["terraform"].(map[string]any)
+			if ok && len(terraformComps) == 0 {
+				emptyStacks = append(emptyStacks, stackName)
+				continue
+			}
+		}
📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between 80bfa6e and f76f914.

📒 Files selected for processing (2)
  • pkg/describe/describe_stacks.go (1 hunks)
  • pkg/describe/describe_stacks_test.go (9 hunks)
🔇 Additional comments (2)
pkg/describe/describe_stacks.go (1)

Line range hint 1-16: STRENGTH AND HONOR! The function signature change is well-crafted, warrior!

The addition of includeEmptyStacks bool parameter aligns perfectly with our mission to filter out empty stacks by default. The parameter name is clear and its position follows Go conventions.

pkg/describe/describe_stacks_test.go (1)

179-250: Well-structured test coverage for empty stacks filtering!

The new test functions provide comprehensive coverage for the empty stacks filtering feature, aligning perfectly with the PR objectives. The tests effectively verify both the inclusion and exclusion of empty stacks based on the includeEmptyStacks flag.

pkg/describe/describe_stacks_test.go Outdated Show resolved Hide resolved
@osterman osterman added the minor New features that do not break anything label Nov 6, 2024
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Outside diff range and nitpick comments (2)
internal/exec/describe_stacks.go (2)

154-176: Consider extracting empty stack detection logic into a separate function.

The current implementation mixes multiple concerns. Extracting this logic would improve readability and maintainability.

+func isStackEmpty(stackSection map[string]any) bool {
+    // Check for explicit components
+    hasExplicitComponents := false
+    if componentsSection, ok := stackSection["components"].(map[string]any); ok {
+        if componentsSection != nil {
+            if terraformSection, ok := componentsSection["terraform"].(map[string]any); ok {
+                hasExplicitComponents = len(terraformSection) > 0
+            }
+            if helmfileSection, ok := componentsSection["helmfile"].(map[string]any); ok {
+                hasExplicitComponents = hasExplicitComponents || len(helmfileSection) > 0
+            }
+        }
+    }
+
+    // Check for imports
+    hasImports := false
+    if importsSection, ok := stackSection["import"].([]any); ok {
+        hasImports = len(importsSection) > 0
+    }
+
+    return !hasExplicitComponents && !hasImports
+}

Then use it in the main function:

-        // Check if components section exists and has explicit components
-        hasExplicitComponents := false
-        if componentsSection, ok := stackSection.(map[string]any)["components"]; ok {
-            if componentsSection != nil {
-                if terraformSection, ok := componentsSection.(map[string]any)["terraform"].(map[string]any); ok {
-                    hasExplicitComponents = len(terraformSection) > 0
-                }
-                if helmfileSection, ok := componentsSection.(map[string]any)["helmfile"].(map[string]any); ok {
-                    hasExplicitComponents = hasExplicitComponents || len(helmfileSection) > 0
-                }
-            }
-        }
-
-        // Also check for imports
-        hasImports := false
-        if importsSection, ok := stackSection.(map[string]any)["import"].([]any); ok {
-            hasImports = len(importsSection) > 0
-        }
-
-        // Skip stacks without components or imports when includeEmptyStacks is false
-        if !includeEmptyStacks && !hasExplicitComponents && !hasImports {
+        if !includeEmptyStacks && isStackEmpty(stackSection.(map[string]any)) {
             continue
         }

Line range hint 1-624: Consider adding metrics for empty stack filtering.

The implementation successfully addresses the requirement. Consider adding metrics to track:

  • Number of empty stacks filtered out
  • Usage patterns of the --include-empty-stacks flag
  • Performance impact of filtering

This would help in understanding the feature's impact and usage patterns.

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

📥 Commits

Reviewing files that changed from the base of the PR and between f76f914 and 7629b93.

📒 Files selected for processing (1)
  • internal/exec/describe_stacks.go (8 hunks)
🔇 Additional comments (2)
internal/exec/describe_stacks.go (2)

58-61: LGTM! Flag implementation is clean and follows standard patterns.


568-624: Improve post-processing filter logic structure and verify edge cases.

The current implementation is complex and could benefit from better organization. Also, we should verify the handling of edge cases.

  1. Extract the component content check into a helper function:
+func hasRelevantContent(compContent map[string]any) bool {
+    relevantSections := []string{"vars", "metadata", "settings", "env", "workspace"}
+    for _, section := range relevantSections {
+        if _, hasSection := compContent[section]; hasSection {
+            return true
+        }
+    }
+    return false
+}
  1. Let's verify the edge cases with this script:
✅ Verification successful

The script results show that the deploy/ prefix handling is working as expected across the codebase, with multiple examples of proper usage in various stack configurations. The naming conflict warnings are related to common configuration file names across different directories, which is a normal pattern in a monorepo structure.

Let's verify the empty stack handling with one more check:


Let's do one final check to verify the empty stack handling with a different approach:


Post-processing filter logic is robust and handles edge cases correctly

The code analysis shows that the empty stack handling and deploy/ prefix logic is well-implemented and thoroughly tested:

  • Empty stacks are properly filtered through the components section validation
  • The deploy/ prefix handling is consistently implemented across multiple example stacks
  • Test files confirm empty stack handling (internal/exec/describe_stacks.go)
  • The code includes proper handling of various edge cases:
    • Empty component sections
    • Missing component types
    • Invalid component configurations
    • Duplicate stack names with deploy/ prefix

The suggested refactoring would be good to have but is not critical as the current implementation is functionally sound.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check for potential edge cases in stack handling

# Look for stacks with only empty sections
rg -l '"components":\s*\{\s*\}' --type json

# Look for stacks with deploy/ prefix to verify canonical name handling
fd -e yaml -e json . | rg "deploy/"

# Look for potential naming conflicts
fd -e yaml -e json . | while read -r file; do
    basename=$(basename "$file")
    if [ "$(fd -e yaml -e json "$basename" | wc -l)" -gt 1 ]; then
        echo "Potential naming conflict found for: $basename"
    fi
done

Length of output: 63109


Script:

#!/bin/bash
# Check for empty component sections and their handling
rg -A 5 '"components":\s*\{' --type json

# Look for any potential edge cases in stack configurations
rg -l '"components":\s*\{[^}]*"terraform":\s*\{\s*\}[^}]*\}' --type json
rg -l '"components":\s*\{[^}]*"helmfile":\s*\{\s*\}[^}]*\}' --type json

Length of output: 5477


Script:

#!/bin/bash
# Search for stack files with empty or minimal component configurations
fd -e yaml -e json . | xargs grep -l "components:" | while read -r file; do
  echo "=== $file ==="
  # Show the components section and a few lines after it for context
  awk '/components:/{p=NR+10}(NR<=p){print}' "$file"
done

# Also check for any test cases handling empty stacks
rg -l "empty.*stack" --type go

Length of output: 63571

internal/exec/describe_stacks.go Show resolved Hide resolved
internal/exec/describe_stacks.go Outdated Show resolved Hide resolved
@@ -55,6 +55,11 @@ func ExecuteDescribeStacksCmd(cmd *cobra.Command, args []string) error {
return err
}

includeEmptyStacks, err := cmd.Flags().GetBool("include-empty-stacks")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
includeEmptyStacks, err := cmd.Flags().GetBool("include-empty-stacks")
includeEmptyStacks, err := flags.GetBool("include-empty-stacks")

@@ -242,9 +286,13 @@ func ExecuteDescribeStacks(

if stackName == "" {
stackName = stackFileName
} else if strings.HasPrefix(stackFileName, "deploy/") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Cerebrovinny why do we need a special treatment for the deploy/ folder?
The deploy/ was just an example in the examples folder, it should not be a special name, and should not be hardcoded in Atmos code

) (map[string]any, error) {

return e.ExecuteDescribeStacks(cliConfig, filterByStack, components, componentTypes, sections, ignoreMissingFiles, true)
return e.ExecuteDescribeStacks(cliConfig, filterByStack, components, componentTypes, sections, ignoreMissingFiles, false, includeEmptyStacks)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
return e.ExecuteDescribeStacks(cliConfig, filterByStack, components, componentTypes, sections, ignoreMissingFiles, false, includeEmptyStacks)
return e.ExecuteDescribeStacks(cliConfig, filterByStack, components, componentTypes, sections, ignoreMissingFiles, true, includeEmptyStacks)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this ExecuteDescribeStacks function is called by the terraform-provider-utils, we should process Go templates

Copy link
Member

@aknysh aknysh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Cerebrovinny thanks, please see comments

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
minor New features that do not break anything
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants