Detect deleted components in affected stacks#2063
Merged
Conversation
Add automatic detection of components and stacks that have been deleted in the current branch compared to the target branch. This enables CI/CD pipelines to trigger terraform destroy workflows for removed infrastructure. Changes: - Add Deleted and DeletionType fields to schema.Affected struct - Add detectDeletedComponents function to find deleted components - Add new affected reasons: deleted, deleted.stack - Add deletion types: component, stack - Skip abstract components (not provisioned) - Add 8 unit tests for deletion detection scenarios - Regenerate posthog mock for new Client interface method Documentation: - Update describe-affected.mdx with new fields and examples - Update affected-stacks.mdx GitHub Actions integration guide - Add blog post for the new feature - Update roadmap with shipped milestone Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
🚀 Go Version Change Detected This PR changes the Go version:
Tip Upgrade Checklist
This is an automated comment from the Go Version Check action. |
|
Warning This PR exceeds the recommended limit of 1,000 lines.Large PRs are difficult to review and may be rejected due to their size. Please verify that this PR does not address multiple issues. |
Dependency ReviewThe following issues were found:
License Issuesgo.mod
Scanned Files
|
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds detection of deleted stacks and components to describe-affected by rescanning BASE vs HEAD, producing Affected entries with new Changes
Sequence DiagramsequenceDiagram
participant CLI as describe-affected CLI
participant Parallel as Parallel Processor
participant Detect as detectDeletedComponents
participant Remote as BASE (remoteStacks)
participant Current as HEAD (currentStacks)
participant Schema as Affected Schema
CLI->>Parallel: compareStacks(Remote, Current, filter)
Parallel->>Parallel: process per-stack diffs (mods)
Parallel->>Detect: detectDeletedComponents(Remote, Current, filter)
Detect->>Remote: iterate remote stacks
alt stack missing in Current
Detect->>Schema: processDeletedStack -> mark components deleted (deletion_type:"stack")
else stack present
Detect->>Current: compare component sets
Detect->>Schema: processDeletedComponentsInStack -> mark missing components deleted (deletion_type:"component")
Detect->>Schema: skip abstract components
end
Detect->>Parallel: return deleted Affected items
Parallel->>CLI: append deletions to final affected list
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2063 +/- ##
==========================================
+ Coverage 76.09% 76.11% +0.02%
==========================================
Files 797 798 +1
Lines 74649 74821 +172
==========================================
+ Hits 56803 56949 +146
- Misses 14300 14321 +21
- Partials 3546 3551 +5
Flags with carried forward coverage won't be shown. Click here to find out more.
🚀 New features to boost your workflow:
|
Contributor
📝 WalkthroughWalkthroughThis PR introduces detection of deleted components and stacks in the describe-affected workflow by comparing BASE (target) and HEAD (current) states. It updates the schema with new fields, extends the detection pipeline for both sequential and parallel flows, adds comprehensive tests and fixtures, and includes documentation and blog post updates. Several Go dependencies are also bumped to newer versions. Changes
Sequence DiagramsequenceDiagram
participant CLI as Describe Affected CLI
participant Detect as Detection Engine
participant BASE as BASE Stacks
participant HEAD as HEAD Stacks
participant Schema as Affected Schema
participant Output as Output
CLI->>Detect: Start describe-affected with BASE & HEAD
activate Detect
Detect->>BASE: Load BASE stacks (remote)
Detect->>HEAD: Load HEAD stacks (current)
Note over Detect: Phase 1: Detect modifications<br/>(existing per-stack comparison)
loop Per-stack modified comparison
Detect->>BASE: Get stack components
Detect->>HEAD: Get stack components
Detect->>Schema: Create Affected items<br/>(modified=true)
end
Note over Detect: Phase 2: Detect deletions<br/>(iterate BASE, check against HEAD)
loop Over BASE stacks
alt Stack missing in HEAD
Detect->>Schema: Mark all non-abstract<br/>components as deleted<br/>(deletion_type: stack)
else Stack exists, check components
loop Over BASE components
alt Component missing in HEAD
Detect->>Schema: Mark component deleted<br/>(deletion_type: component)
else Abstract component
Detect->>Detect: Skip (abstract)
end
end
end
end
deactivate Detect
Schema->>Output: Return combined affected list<br/>(modified + deleted)
Output->>CLI: Display results with deleted flag
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly Related PRs
Suggested Reviewers
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@docs/prd/describe-affected-deleted-detection.md`:
- Around line 46-51: The PRD and implementation disagree: the code defines
affectedReasonDeleted = "deleted" and affectedReasonDeletedStack =
"deleted.stack" but there is no "deleted.component" or "component_instance" in
the implementation; update the PRD to match the code by replacing
`deleted.component` with `deleted` (or add a note that `deleted` covers
component deletions) and change the deletion types table to list only
`component` and `stack` (or `deleted`/`deleted.stack` as the canonical reason
strings), or alternatively add corresponding constants/handlers (e.g., a new
affectedReasonDeletedComponent = "deleted.component" and support for
"component_instance") if you prefer changing code instead of docs—refer to
affectedReasonDeleted, affectedReasonDeletedStack, `deleted.component`, and
`component_instance` when making the change.
In `@internal/exec/describe_affected_utils.go`:
- Around line 119-122: The current code swallows every error from
FindAllStackConfigsInPathsForStack by unconditionally setting
remoteStackConfigFilesAbsolutePaths = []string{}, which can hide real failures;
change the handling to detect the specific "no manifests found" condition (e.g.,
compare err to the package's sentinel like ErrNoManifests or inspect the error
message/type returned by FindAllStackConfigsInPathsForStack) and only set
remoteStackConfigFilesAbsolutePaths to an empty slice in that case, otherwise
propagate or return the unexpected error (or at minimum log it at debug via your
logger) so callers of the surrounding function in describe_affected_utils.go
receive real errors instead of silent success.
🧹 Nitpick comments (4)
website/blog/2026-02-08-describe-affected-deleted-detection.mdx (1)
110-118: Consider adding the same safety warning present in the docs.The destroy job uses
--auto-approvewithout a manual approval gate. The affected-stacks docs include a:::warningabout reviewing deletions first. Worth adding a similar note here so readers of the blog post alone get the same guidance.website/src/data/roadmap.js (1)
346-346: Missingprfield on the new milestone.Other shipped milestones include a
prnumber for traceability. Consider addingpr: 2063here.Suggested fix
- { label: 'Deleted component detection for destroy workflows', status: 'shipped', quarter: 'q1-2026', docs: '/cli/commands/describe/affected', changelog: 'describe-affected-deleted-detection', description: 'Automatically detect components and stacks that have been deleted in the current branch compared to the target branch. Enables CI/CD pipelines to trigger terraform destroy workflows for removed infrastructure.', category: 'featured', priority: 'high', benefits: 'CI/CD pipelines can now separate apply and destroy workflows automatically. No more orphaned cloud resources from removed components.' }, + { label: 'Deleted component detection for destroy workflows', status: 'shipped', quarter: 'q1-2026', pr: 2063, docs: '/cli/commands/describe/affected', changelog: 'describe-affected-deleted-detection', description: 'Automatically detect components and stacks that have been deleted in the current branch compared to the target branch. Enables CI/CD pipelines to trigger terraform destroy workflows for removed infrastructure.', category: 'featured', priority: 'high', benefits: 'CI/CD pipelines can now separate apply and destroy workflows automatically. No more orphaned cloud resources from removed components.' },As per coding guidelines, PRs labeled minor/major MUST update
website/src/data/roadmap.jswith milestone status, changelog link, PR link, and initiative progress percentage.internal/exec/describe_affected_test.go (1)
1449-1449: Loosestrings.Containscheck could match unintended stacks.The fallback
strings.Contains(a.Stack, "production")is understandable for unprocessed templates, but in a larger fixture it could match stacks like"non-production-staging". Since the fixture is controlled this is fine for now, but a more precise regex or suffix match would be more robust.internal/exec/describe_affected_deleted.go (1)
214-229: Deleted items don't populate optional metadata fields that non-deleted items do.Affected items for non-deleted components set
Environmentfrom stack vars. Deleted items skipNamespace,Tenant,Environment,Stage,SpaceliftStack,AtlantisProject, and others. While these fields are optional (omitempty), downstream consumers filtering or grouping by tenant/environment for destroy operations might expect consistency.The
deletedItemParamsprovides access to the BASE component section's metadata—extracting and populating these fields would improve output completeness if other parts of the toolchain depend on them.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
NOTICE (1)
1-4:⚠️ Potential issue | 🟡 MinorPipeline failure: NOTICE file is out of date.
The Dependency Review CI check is failing with:
NOTICE file is out of date. Run './scripts/generate-notice.sh' locally and commit the changes.Since this file is programmatically generated, regenerate it to pass CI.
🤖 Fix all issues with AI agents
In `@docs/prd/describe-affected-deleted-detection.md`:
- Around line 46-51: Update the PRD to match the shipped implementation: replace
any mention of the non-existent reason `deleted.component` with the actual
reason `deleted`, and remove `component_instance` as a deletion type—only
document `component` and `stack` as supported deletion types (keep the table
rows/headers consistent with the implemented values `deleted`, `component`, and
`stack`).
In `@internal/exec/describe_affected_deleted.go`:
- Around line 136-140: The current branch incorrectly delegates to
processDeletedStack when currentComponentsSection is missing, which labels the
whole stack as deleted; instead detect this edge case and treat it as
"components removed" by iterating remoteComponentsSection's components and
emitting per-component deletions with deletion_type "component" and affected
"deleted" (or call a new helper like processDeletedComponents(stackName,
remoteComponentsSection, atmosConfig)); replace the processDeletedStack(...)
call in the currentComponentsSection nil branch with that per-component handling
so the stack is not marked as a deleted.stack.
- Around line 214-230: createDeletedAffectedItem currently omits context fields;
call GetContextFromVars(params.componentSection) inside
createDeletedAffectedItem (using the same pattern as non-deleted items), extract
Namespace, Tenant, Environment, and Stage from its return and assign them to
affected.Namespace, affected.Tenant, affected.Environment, and affected.Stage
before returning; reference the function name createDeletedAffectedItem, the
params struct deletedItemParams, and GetContextFromVars to locate where to add
these assignments.
In `@internal/exec/describe_affected_utils.go`:
- Around line 101-123: The code currently swallows all errors from
cfg.FindAllStackConfigsInPathsForStack and treats any failure as "all stacks
deleted"; change this so only the specific "no matches" sentinel error from the
cfg package is treated as an empty list (set remoteStackConfigFilesAbsolutePaths
= []string{}), and any other error is returned up the stack. Update the error
handling after the call to FindAllStackConfigsInPathsForStack to use
errors.Is(err, cfg.<sentinelErrName>) (or inspect the returned error type if cfg
provides a typed error) to detect the "no stack manifests" case; for all other
errors, return nil, nil, nil, err. Ensure references to
FindAllStackConfigsInPathsForStack, remoteStackConfigFilesAbsolutePaths, and
atmosConfig.StackConfigFilesAbsolutePaths remain unchanged.
In `@website/docs/integrations/github-actions/affected-stacks.mdx`:
- Around line 74-86: The destroy job currently runs atmos terraform destroy with
--auto-approve while the following warning advises manual review; update the
GitHub Actions workflow (the destroy job and its steps) to remove the
--auto-approve flag and/or add an explicit approval step (e.g., a manual
approval job or required reviewers via an environment) before the run step that
executes atmos terraform destroy ${{ matrix.component }} -s ${{ matrix.stack }}
so the workflow enforces human confirmation consistent with the warning.
In `@website/src/data/roadmap.js`:
- Line 346: The new roadmap milestone object with label 'Deleted component
detection for destroy workflows' is missing the required pr field; update that
milestone object (the entry with label 'Deleted component detection for destroy
workflows') to include pr: 'https://github.com/your-repo/pull/2063' (or the
canonical PR link for `#2063`) so it matches other milestones and satisfies the
guideline about including PR links in website/src/data/roadmap.js; keep the rest
of the fields unchanged and ensure the string format matches existing pr
entries.
🧹 Nitpick comments (4)
docs/prd/describe-affected-deleted-detection.md (1)
185-228: CI/CD example uses--auto-approveon destroy — worth a safety callout.Line 227 shows
atmos terraform destroy ... --auto-approvein the example workflow. This is fine as a reference, but a brief note recommending a manual approval gate (e.g., GitHub Environment protection rules) for production destroy workflows would strengthen the guidance.internal/exec/describe_affected_test.go (1)
1447-1449: Loose production stack matching could catch unintended stacks.
strings.Contains(a.Stack, "production")would match any stack name containing "production" (e.g.,"pre-production-us-east-1"). It works in this fixture since there's only one such stack, but it's fragile if the fixture grows.Consider tightening to
strings.HasSuffixor an exact match + the unprocessed template variant:Proposed tightening
- isProductionStack := a.Stack == "ue1-production" || strings.Contains(a.Stack, "production") + isProductionStack := a.Stack == "ue1-production" || strings.HasSuffix(a.Stack, "-production")website/docs/cli/commands/describe/describe-affected.mdx (2)
1107-1107: Nit: "vs" → "vs." for American English.Static analysis flagged this. In American English convention, abbreviations typically get a period.
-## Detecting Deleted Components for Destruction Workflows +## Detecting Deleted Components for Destroy WorkflowsAlternatively, just add the period: "Deleted vs. Modified Components" on line 1124.
1139-1186: CI/CD example is practical — one thing to note on the destroy step.The
--auto-approveon Line 1185 bypasses confirmation. The warning block on Lines 1188-1191 correctly flags this as irreversible. Consider adding a manual approval step in the example to reinforce the warning:Suggested addition
destroy: needs: detect-changes if: needs.detect-changes.outputs.deleted != '[]' + environment: production # Requires manual approval strategy:This would make the example more aligned with the "consider adding manual approval steps" guidance in the warning.
- Populate metadata fields (Namespace, Tenant, Environment, Stage) for deleted components from BASE vars section - Add Spacelift stack and Atlantis project names for deleted Terraform components - Add debug logging when BASE stack manifest discovery fails - Fix PRD to match implementation (remove non-existent deleted.component reason and component_instance deletion type) - Use strings.HasSuffix instead of strings.Contains in test - Add safety warning to blog post about --auto-approve - Add PR number to roadmap milestone Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@website/blog/2026-02-08-describe-affected-deleted-detection.mdx`:
- Around line 114-122: The CI example's destroy (and apply) matrix jobs rely on
repository files and atmos but omit a checkout and atmos install, so add an
actions/checkout step and the same atmos installation used elsewhere at the
start of the destroy job (and mirror into apply) before running atmos commands;
locate the destroy job and its steps (job name: destroy, matrix: include, step
running `atmos terraform destroy ${ matrix.component } -s ${ matrix.stack }
--auto-approve`) and insert an `actions/checkout` step plus the atmos install
step used in detect-changes/apply so the matrix runners have the repo and atmos
available.
🧹 Nitpick comments (2)
internal/exec/describe_affected_test.go (1)
1448-1451:HasSuffix("-production")could match unintended stacks.The comment explains this handles unprocessed template names, which is fair. But
HasSuffix(a.Stack, "-production")would also match stacks likenon-productionorpre-production. The test fixtures likely don't have such names, but this is fragile.Consider a tighter check if the fixture set grows:
Suggestion
- isProductionStack := a.Stack == "ue1-production" || strings.HasSuffix(a.Stack, "-production") + isProductionStack := a.Stack == "ue1-production" || strings.HasSuffix(a.Stack, "-production") || a.Stack == "production"Or use a regex like
\bproduction$if needed. Fine for now given the controlled fixture set.internal/exec/describe_affected_deleted.go (1)
240-265:populateDeletedItemMetadatausesmapstructure.Decodeinstead ofcfg.GetContextFromVars.The existing codebase uses
cfg.GetContextFromVars(varsSection)to extract context from vars (seespacelift_utils.go:108,atlantis_utils.go:39). Usingmapstructure.Decodedirectly works but diverges from the established pattern.Consider using
cfg.GetContextFromVarsfor consistency:Suggestion
- var context schema.Context - if err := mapstructure.Decode(varsSection, &context); err != nil { - // If decoding fails, skip metadata population but continue. - return - } + context := cfg.GetContextFromVars(varsSection)This also removes the
mapstructureimport from this file.
- Add ErrNoStackManifestsFound sentinel error and use errors.Is() instead of string checking for proper error handling - Use cfg.GetContextFromVars() instead of mapstructure.Decode for consistency with spacelift_utils.go and atlantis_utils.go - Refactor processDeletedStack to use processAllComponentsAsDeleted helper with configurable deletion type/reason - Fix edge case: stack exists but lacks components section now correctly uses deletion_type: "component" instead of "stack" - Add environment protection and checkout steps to CI/CD examples - Fix "vs" -> "vs." for American English - Add exact "production" stack name check in test - Use correct GitHub Action: cloudposse/github-action-setup-atmos@v2 Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Fix all issues with AI agents
In `@docs/prd/describe-affected-deleted-detection.md`:
- Line 99: Replace the informal "vs" with the American English abbreviation
"vs." in the user-facing phrases identified (e.g., the sentence containing
"Users can filter the output using `--query` to separate modified vs deleted
components" and the phrase "moves vs deletes"); update those occurrences so they
read "vs." (with a period) to conform to the style convention.
- Around line 213-231: The apply and destroy jobs currently run atmos commands
on fresh runners without checking out the repo or installing Atmos; add initial
steps in the apply and destroy job definitions to (1) checkout the repository
using actions/checkout (or equivalent) and (2) install or set up the Atmos CLI
(e.g., use the official Atmos setup action or install via package manager/curl)
before the run: atmos terraform ... steps so the matrix-mounted ${
matrix.component } and ${ matrix.stack } commands execute successfully.
In `@internal/exec/describe_affected_deleted.go`:
- Around line 134-137: The //nolint rationale on the
processDeletedComponentsInStack function is missing a trailing period; update
the comment line (above processDeletedComponentsInStack) to end with a period
(e.g., "//nolint:funlen,revive // function-length: logic is straightforward,
splitting would reduce readability.") and apply the same fix to the other nolint
rationale comments in the same file (around lines referenced 151-209) so every
inline rationale sentence terminates with a period.
In `@website/docs/cli/commands/describe/describe-affected.mdx`:
- Around line 1143-1187: The apply and destroy jobs (job names "apply" and
"destroy") are missing repository checkout and Atmos CLI setup so their atmos
terraform commands will fail on fresh runners; add steps at the start of each
job to run actions/checkout@v4 (with fetch-depth: 0) and to install/configure
the Atmos CLI (a step that ensures atmos is on PATH) before the step that runs
"atmos terraform apply ${{ matrix.component }} -s ${{ matrix.stack }}" and
"atmos terraform destroy ${{ matrix.component }} -s ${{ matrix.stack }}
--auto-approve" respectively so the commands can execute successfully.
🧹 Nitpick comments (1)
website/docs/cli/commands/describe/describe-affected.mdx (1)
690-754: Documentation fordeletedanddeleted.stackaffected reasons is thorough with good examples.One minor note: these entries are wedged between
fileandfolderin the<dl>list. Grouping deletion reasons at the end (afterfolder) might read more naturally since they represent a different category of change. Not blocking — just a thought.
- Fix TestDetectDeletedComponents_NoComponentsSection to expect deletion_type: "component" (not "stack") when stack exists but lacks components section - Update PRD with complete CI/CD example (checkout + atmos setup) - Add safety warning about --auto-approve in destroy workflows - Fix "vs" to "vs." for American English consistency - Improve nolint directive explanation for processDeletedComponentsInStack - Update docs with complete CI/CD examples Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Contributor
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
1 similar comment
Contributor
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@website/docs/cli/commands/describe/describe-affected.mdx`:
- Around line 1181-1192: The destroy job as written will attempt to run atmos
terraform destroy after actions/checkout@v4 checks out the PR HEAD, but deleted
component files won't exist there causing atmos terraform destroy (invoked with
matrix.component and matrix.stack) to fail because it cannot find the component
config/state; update the workflow/docs to either (a) checkout the BASE/target
branch instead of HEAD before the destroy step, or (b) checkout both branches
and pass --repo-path pointing at the BASE checkout to atmos terraform destroy,
and add a clear callout next to the destroy job describing this caveat and
recommended approaches.
🧹 Nitpick comments (1)
internal/exec/describe_affected_deleted_test.go (1)
14-328: Consider adding error-path andComponentPathassertion coverage.Two gaps worth considering for a follow-up:
- No error-path tests: All tests assert
require.NoError. There's no test feeding malformed stack data (e.g.,componentskey that isn't amap[string]any) to verify graceful error handling or safe fallback.ComponentPathnot asserted: None of the tests checkdeleted[i].ComponentPath. For deleted components (sourced from BASE), this field may intentionally be empty, but it would be good to assert that explicitly so future refactors don't silently regress.Neither blocks this PR — just worth a quick follow-up.
- Add error-path tests for malformed stack data (graceful handling) - Add ComponentPath assertion test with Windows-compatible paths - Fix destroy job in CI/CD examples to checkout BASE branch (deleted component config only exists in BASE, not HEAD) - Add explanation in docs about BASE branch requirement - Update CLAUDE.md with Windows test compatibility guidelines Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
osterman
reviewed
Feb 9, 2026
website/blog/2026-02-08-describe-affected-deleted-detection.mdx
Outdated
Show resolved
Hide resolved
osterman
reviewed
Feb 9, 2026
osterman
previously approved these changes
Feb 9, 2026
aknysh
changed the title
- Add deleted and deletion_type fields to affected extraction - Add tests for deleted component handling in list affected - Update list-affected docs with deleted fields and examples - Update blog post with list affected section - Update PRD with list affected integration - Update roadmap milestone label Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
aknysh
dismissed stale reviews from osterman and coderabbitai[bot]
via
43d241b
|
These changes were released in v1.206.0-rc.4. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
what
atmos describe affectednow detects components and stacks that have been deleted in HEAD (current branch) compared to BASE (target branch)deleted(boolean) anddeletion_type(string:componentorstack) fields to the affected output schemadeletedanddeleted.stackas valid affected reasonstests/fixtures/scenarios/atmos-describe-affected-deleted-detection/describe-affected.mdxwith new fields, reasons, and CI/CD workflow examplesaffected-stacks.mdxfor destroy workflow integrationwhy
terraform destroyHow It Works
The algorithm now performs a second pass over BASE stacks to detect deletions:
For each stack in BASE:
deleted.stackdeletedAbstract components (
metadata.type: abstract) are not reported as deleted since they are blueprints and not provisionedCI/CD Integration
Users can now separate apply and destroy workflows:
Test Coverage
8 unit tests for deletion detection logic covering:
2 integration tests using new fixture:
TestDescribeAffectedDeletedComponentDetectionTestDescribeAffectedDeletedComponentFilteringreferences
docs/prd/describe-affected-deleted-detection.mdSummary by CodeRabbit
New Features
Documentation
Tests
Chores
Mocks
Errors