feat: Support Component Lock with metadata.locked
#908
Conversation
milldr
added
minor
|
Warning Rate limit exceeded@milldr has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 4 minutes and 20 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. 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe pull request introduces a new Changes
Assessment against linked issues
Suggested reviewersThank 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: 0
🧹 Nitpick comments (2)
internal/exec/utils.go (2)
135-135: Maintain consistent ordering.It might be clearer to set
ComponentIsLockedimmediately after settingComponentIsEnabledto group similar fields and make the code more readable.133 componentMetadata, baseComponentName, componentIsAbstract, componentIsEnabled, componentIsLocked := ProcessComponentMetadata(component, componentSection) 134 configAndStacksInfo.ComponentIsEnabled = componentIsEnabled -135 configAndStacksInfo.ComponentIsLocked = componentIsLocked +135 configAndStacksInfo.ComponentIsLocked = componentIsLocked
606-606: Similar comment on consistent ordering.For consistency, consider placing
ComponentIsLockedright after settingComponentIsEnabled.603 _, baseComponentName, _, componentIsEnabled, componentIsLocked := ProcessComponentMetadata(configAndStacksInfo.ComponentFromArg, configAndStacksInfo.ComponentSection) 604 configAndStacksInfo.BaseComponentPath = baseComponentName 605 configAndStacksInfo.ComponentIsEnabled = componentIsEnabled -606 configAndStacksInfo.ComponentIsLocked = componentIsLocked +607 configAndStacksInfo.ComponentIsLocked = componentIsLocked
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
internal/exec/helmfile.go(1 hunks)internal/exec/stack_utils.go(3 hunks)internal/exec/terraform.go(1 hunks)internal/exec/utils.go(2 hunks)pkg/schema/schema.go(1 hunks)pkg/spacelift/spacelift_stack_processor.go(1 hunks)website/docs/core-concepts/stacks/define-components.mdx(1 hunks)
🔇 Additional comments (12)
internal/exec/stack_utils.go (5)
58-58: Nicely expanded comment.Clear documentation improves maintainability. Good job clarifying that we also check the locked state here.
62-62: Expanded return signature.Returning the locked state is consistent with the rest of the code. This ensures that callers can decide how to handle a locked component.
66-66: Good default initialization.Setting
componentIsLockedto false by default is intuitive. Components remain unlocked unless explicitly stated otherwise.
86-90: Conditional assignment of locked state.The logic for reading
lockedfrom metadata is straightforward. This effectively flags components as locked in subsequent checks.
103-103: Returning locked status.Including
componentIsLockedin the returned tuple finalizes the integration. This is well-aligned with the updated usage across the codebase.internal/exec/helmfile.go (1)
97-105: Locked component guard.Preventing modification commands for locked components is consistent with the PR’s objective. This ensures safer state management.
pkg/spacelift/spacelift_stack_processor.go (1)
175-175: Ignored locked state.Using the underscore indicates ignoring the locked flag here. If needed later, it can be utilized without disrupting existing code.
internal/exec/terraform.go (1)
125-134: Locked component enforcement.Smart to prevent destructive commands on locked components. This matches the approach in the Helmfile logic.
pkg/schema/schema.go (1)
234-234: Great introduction of the locked field.Adding
ComponentIsLockedprovides a clear way to track and enforce locking at the schema level.internal/exec/utils.go (2)
133-133: Good job capturing the locked status.Storing
componentIsLockedimmediately after retrieving it fromProcessComponentMetadataensures the correct flow of information.
603-603: Good reuse ofProcessComponentMetadata.This ensures that the locked status is always determined at the same time as abstract/enabled status.
website/docs/core-concepts/stacks/define-components.mdx (1)
237-259: Helpful new section.Documenting
metadata.lockedclarifies how teams can control authorized usage. The example is concise and demonstrates a real-life scenario for safeguarding critical infrastructure.
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (6)
examples/demo-metadata/atmos.yaml (1)
10-10: Clean up the battlefield - remove trailing spaces.There are trailing spaces at the end of line 10.
- +🧰 Tools
🪛 yamllint (1.35.1)
[error] 10-10: trailing spaces
(trailing-spaces)
examples/demo-metadata/components/terraform/myapp/main.tf (1)
11-16: STRENGTHEN YOUR DEFENSES, BRAVE ONE!While the HTTP data source is functional, we can make it more resilient in battle:
data "http" "weather" { url = local.url request_headers = { User-Agent = "curl" } + retry { + attempts = 3 + min_delay_ms = 1000 + max_delay_ms = 5000 + } + timeout = "10" }examples/demo-metadata/components/terraform/myapp/outputs.tf (1)
1-27: WELL-STRUCTURED OUTPUTS, BUT LET'S POLISH OUR PROCLAMATIONS!Your output structure is strong, but let's refine the descriptions for clarity:
output "location" { value = var.location - description = "Location of the weather report." + description = "Location for the weather report" } output "lang" { value = var.lang - description = "Language which the weather is displayed." + description = "Language in which the weather is displayed" } output "units" { value = var.units - description = "Units the weather is displayed." + description = "Units in which the weather is displayed" }examples/demo-metadata/components/terraform/myapp/variables.tf (1)
1-34: STRONG VARIABLE DECLARATIONS, FELLOW WARRIOR!Your variable structure is robust, but let's enhance the clarity of our battle plan:
- Improve descriptions:
variable "location" { - description = "Location for which the weather." + description = "Location for which to fetch the weather report" }
- Consider adding validation rules for critical variables:
variable "stage" { description = "Stage where it will be deployed" type = string + validation { + condition = contains(["dev", "staging", "prod"], var.stage) + error_message = "Stage must be one of: dev, staging, prod." + } } variable "units" { description = "Units in which the weather is displayed." type = string default = "m" + validation { + condition = contains(["m", "u", "M"], var.units) + error_message = "Units must be one of: m (metric), u (USCS), M (metric with wind in m/s)." + } }tests/test_cases.yaml (1)
219-233: Excellent negative test case for locked component protection!The test effectively validates that locked components cannot be modified, with a clear error message. Consider adding additional test cases for:
- Read-only operations (like plan) on locked components
- Other commands that should be blocked on locked components
examples/demo-metadata/components/terraform/myapp/README.md (1)
1-14: Add component locking information to features sectionSince this example is in the
demo-metadatadirectory and is used in the locking test cases, consider adding information about the component locking feature to demonstrate real-world usage ofmetadata.locked.🧰 Tools
🪛 LanguageTool
[typographical] ~3-~3: Consider using typographic quotation marks here.
Context: ...aform Weather Component This Terraform "root" module fetches weather information for ...(EN_QUOTES)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
examples/demo-metadata/.gitignore(1 hunks)examples/demo-metadata/atmos.yaml(1 hunks)examples/demo-metadata/components/terraform/myapp/README.md(1 hunks)examples/demo-metadata/components/terraform/myapp/main.tf(1 hunks)examples/demo-metadata/components/terraform/myapp/outputs.tf(1 hunks)examples/demo-metadata/components/terraform/myapp/variables.tf(1 hunks)examples/demo-metadata/components/terraform/myapp/versions.tf(1 hunks)examples/demo-metadata/stacks/catalog/myapp.yaml(1 hunks)examples/demo-metadata/stacks/deploy/nonprod.yaml(1 hunks)examples/demo-metadata/stacks/deploy/prod.yaml(1 hunks)tests/test_cases.yaml(1 hunks)
✅ Files skipped from review due to trivial changes (3)
- examples/demo-metadata/components/terraform/myapp/versions.tf
- examples/demo-metadata/stacks/catalog/myapp.yaml
- examples/demo-metadata/.gitignore
🧰 Additional context used
🪛 yamllint (1.35.1)
examples/demo-metadata/atmos.yaml
[error] 10-10: trailing spaces
(trailing-spaces)
🪛 LanguageTool
examples/demo-metadata/components/terraform/myapp/README.md
[typographical] ~3-~3: Consider using typographic quotation marks here.
Context: ...aform Weather Component This Terraform "root" module fetches weather information for ...
(EN_QUOTES)
[uncategorized] ~34-~34: Loose punctuation mark.
Context: ... where it will be deployed. - location: Location for which the weather is repor...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~34-~34: Consider using typographic quotation marks here.
Context: ...ich the weather is reported. Default is "Los Angeles". - options: Options to customize the ...
(EN_QUOTES)
[uncategorized] ~35-~35: Loose punctuation mark.
Context: ...d. Default is "Los Angeles". - options: Options to customize the output. Defaul...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~35-~35: Consider using a typographic opening quote here.
Context: ...ons to customize the output. Default is "0T". - format: Specifies the output fo...
(EN_QUOTES)
[typographical] ~35-~35: Consider using a typographic close quote here.
Context: ... to customize the output. Default is "0T". - format: Specifies the output forma...
(EN_QUOTES)
[uncategorized] ~36-~36: Loose punctuation mark.
Context: ... the output. Default is "0T". - format: Specifies the output format. Default is...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~36-~36: Consider using a typographic opening quote here.
Context: ...Specifies the output format. Default is "v2". - lang: Language in which the wea...
(EN_QUOTES)
[typographical] ~36-~36: Consider using a typographic close quote here.
Context: ...cifies the output format. Default is "v2". - lang: Language in which the weathe...
(EN_QUOTES)
[uncategorized] ~37-~37: Loose punctuation mark.
Context: ...output format. Default is "v2". - lang: Language in which the weather will be d...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~37-~37: Consider using typographic quotation marks here.
Context: ...e weather will be displayed. Default is "en". - units: Units in which the weather ...
(EN_QUOTES)
[uncategorized] ~38-~38: Loose punctuation mark.
Context: ...be displayed. Default is "en". - units: Units in which the weather will be disp...
(UNLIKELY_OPENING_PUNCTUATION)
[typographical] ~38-~38: Consider using typographic quotation marks here.
Context: ...e weather will be displayed. Default is "m". ### Outputs - weather: The fetched ...
(EN_QUOTES)
[uncategorized] ~42-~42: Loose punctuation mark.
Context: ...ther: The fetched weather data. - url: Requested URL. - stage`: Stage of depl...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~43-~43: Loose punctuation mark.
Context: ... data. - url: Requested URL. - stage: Stage of deployment. - location: Loca...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~44-~44: Loose punctuation mark.
Context: ...tage: Stage of deployment. - location: Location of the reported weather. - la...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~45-~45: Loose punctuation mark.
Context: ...cation of the reported weather. - lang: Language used for weather data. - `unit...
(UNLIKELY_OPENING_PUNCTUATION)
[uncategorized] ~46-~46: Loose punctuation mark.
Context: ...anguage used for weather data. - units: Units of measurement for the weather da...
(UNLIKELY_OPENING_PUNCTUATION)
🔇 Additional comments (6)
examples/demo-metadata/stacks/deploy/nonprod.yaml (1)
1-14: Well-structured nonprod configuration, warrior!The configuration follows best practices with schema validation and clear environment-specific settings. The absence of component locking is appropriate for a nonprod environment where changes are expected.
examples/demo-metadata/stacks/deploy/prod.yaml (1)
12-13: Strong protection for production components, commander!The
metadata.locked: truesetting effectively prevents accidental modifications to the production component while maintaining read access. This aligns perfectly with the PR's objective of enhancing deployment safety.examples/demo-metadata/atmos.yaml (2)
6-9: Battle-hardened terraform configuration, strategist!The configuration demonstrates strong security consciousness with:
apply_auto_approve: falserequiring explicit approvaldeploy_run_init: trueensuring proper initializationinit_run_reconfigure: truemaintaining configuration consistency
13-16: Well-defined stack boundaries, tactician!The stack configuration effectively manages deployment scope through:
- Explicit inclusion of deploy paths
- Strategic exclusion of defaults
examples/demo-metadata/components/terraform/myapp/main.tf (1)
1-9: STRONG WORK, WARRIOR! URL construction is well-fortified!The URL construction shows excellent defensive programming with proper URL encoding for all parameters. This is the way of the secure warrior!
Let's verify the URL construction with this battle plan:
✅ Verification successful
VICTORY! All variables are properly declared and documented, brave warrior!
The verification shows that all variables used in the URL construction (
location,options,format,lang, andunits) are properly defined in the correspondingvariables.tffile with clear descriptions. This ensures robust and maintainable code structure.The battle-tested URL construction can proceed with confidence!
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Verify that all variables used in the URL construction are properly defined rg -A 1 'variable "(location|options|format|lang|units)"' .Length of output: 4016
tests/test_cases.yaml (1)
201-217: Strong test case for unlocked component deployment!The test case effectively validates that terraform deploy works as expected on unlocked components. The assertions are well-structured, checking both successful execution and clean stderr output.
Let's verify the test environment is properly set up:
✅ Verification successful
Test environment is properly configured for unlocked component validation!
The test case is well-structured and the environment is correctly set up:
- Component
myappis properly defined in the catalog with default configuration- The nonprod stack correctly imports and overrides the component settings
- No lock files are present, confirming the component is indeed unlocked
- The test's working directory and component name align with the actual configuration
This verification confirms that the test case will effectively validate terraform deployment behavior for unlocked components. Stand strong, warrior! Your test shall guard against unwanted regressions.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the demo-metadata example directory contains necessary component configuration fd -t f "stack.y*ml" examples/demo-metadata/stacks/ -x cat {} \; | grep -A 5 "myapp:"Length of output: 88
Script:
#!/bin/bash # Let's check if the directory exists and list its contents ls -la examples/demo-metadata/stacks/ # Check for any yaml files in the examples/demo-metadata directory and its subdirectories fd -e yml -e yaml . examples/demo-metadata/ # Let's try to find any references to myapp in yaml files rg -l "myapp" examples/demo-metadata/Length of output: 669
Script:
#!/bin/bash # Let's check the content of the relevant files to verify the myapp component configuration cat examples/demo-metadata/stacks/catalog/myapp.yaml cat examples/demo-metadata/stacks/deploy/nonprod.yaml # Also check if there are any lock files that might affect the component fd -e lock.hcl . examples/demo-metadata/Length of output: 661
|
💥 This pull request now has conflicts. Could you fix it @milldr? 🙏 |
tests/fixtures/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
examples/quick-start-advanced/stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json (1)
353-355: Well structured schema addition for component locking!The
lockedproperty is well-placed in the metadata section and maintains backward compatibility. The description effectively communicates its purpose.Consider enhancing the description to be more specific about which operations are considered "modifications" vs "read operations". Here's a suggested improvement:
- "description": "Flag to lock the component and prevent modifications while allowing read operations" + "description": "Flag to lock the component. When true, prevents destructive operations (apply, deploy, destroy) while allowing read-only operations (plan, diff)"website/static/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json (1)
352-356: Well structured implementation of the component locking mechanism!The
lockedproperty is well-positioned within themetadatasection, making it available to both Terraform and Helmfile components. The boolean type and clear description effectively communicate its purpose.However, consider adding examples in the schema description to illustrate common use cases:
"locked": { "type": "boolean", - "description": "Flag to lock the component and prevent modifications while allowing read operations" + "description": "Flag to lock the component and prevent modifications while allowing read operations. Example: Set to 'true' to prevent accidental changes to production components while still allowing 'plan' operations" }
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
.gitignore(1 hunks)examples/quick-start-advanced/stacks/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json(1 hunks)tests/fixtures/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json(1 hunks)website/static/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- .gitignore
🚧 Files skipped from review as they are similar to previous changes (1)
- tests/fixtures/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json
⏰ Context from checks skipped due to timeout of 90000ms (2)
- GitHub Check: Acceptance Tests (windows-latest, windows)
- GitHub Check: Summary
🔇 Additional comments (1)
website/static/schemas/atmos/atmos-manifest/1.0/atmos-manifest.json (1)
352-356: Verify schema integration with component implementationsLet's ensure the schema changes are properly integrated with the component implementations.
✅ Verification successful
Schema integration verified and properly implemented
The
metadata.lockedschema property is correctly integrated with both Terraform and Helmfile component implementations, with consistent behavior for blocking modifications while allowing read operations.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the usage of metadata.locked across the codebase # Check for metadata.locked references in Go files echo "Checking Go implementations..." rg -t go "metadata.*locked" -A 5 # Check for metadata.locked usage in test files echo "Checking test files..." rg -g "*.y*ml" "metadata:" -A 10 # Check for any potential validation implementations echo "Checking validation implementations..." rg -t go "ValidateComponent.*lock" -A 5Length of output: 68559
…/atmos into feat/DEV-2849_metadata-locked
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (3)
website/docs/core-concepts/stacks/define-components.mdx (1)
237-258: Consider adding error message examplesThe documentation would benefit from showing example error messages that users will encounter when attempting to modify a locked component. This would help users understand how the feature manifests in practice.
Consider adding a section like this:
Using the `metadata.locked` flag helps protect critical infrastructure from unintended modifications while still allowing teams to inspect and review the configuration. + + When attempting to modify a locked component, users will see an error message similar to: + ``` + Error: Component "rds" is locked and cannot be modified + The component has been marked as locked using metadata.locked. This is to prevent + accidental changes. To modify this component, first unlock it by setting + metadata.locked: false + ```tests/fixtures/scenarios/metadata/atmos.yaml (2)
3-10: Remove trailing whitespace, warrior!A true spartan's code is clean and precise. There's a trailing space on line 10 that needs to be removed.
- +🧰 Tools
🪛 yamllint (1.35.1)
[error] 10-10: trailing spaces
(trailing-spaces)
11-17: Consider adding example of locked component configuration.For the glory of clear documentation! Since this fixture tests metadata features, it would be beneficial to include an example of the new
metadata.lockedconfiguration to demonstrate its usage.Example addition:
stacks: components: example: metadata: locked: true
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
internal/exec/terraform.go(1 hunks)internal/exec/utils.go(2 hunks)pkg/schema/schema.go(1 hunks)tests/fixtures/scenarios/metadata/atmos.yaml(1 hunks)website/docs/core-concepts/stacks/define-components.mdx(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- internal/exec/terraform.go
- pkg/schema/schema.go
🧰 Additional context used
📓 Learnings (1)
tests/fixtures/scenarios/metadata/atmos.yaml (1)
Learnt from: aknysh
PR: cloudposse/atmos#0
File: :0-0
Timestamp: 2025-01-10T15:18:27.794Z
Learning: The `atmos validate stacks` command now uses an embedded JSON Schema by default for validating Atmos manifests, falling back to the schema specified in `atmos.yaml` or via command-line flags if provided.
🪛 yamllint (1.35.1)
tests/fixtures/scenarios/metadata/atmos.yaml
[error] 10-10: trailing spaces
(trailing-spaces)
⏰ Context from checks skipped due to timeout of 90000ms (4)
- GitHub Check: Acceptance Tests (macos-latest, macos)
- GitHub Check: Acceptance Tests (windows-latest, windows)
- GitHub Check: [localstack] demo-localstack
- GitHub Check: Summary
🔇 Additional comments (8)
website/docs/core-concepts/stacks/define-components.mdx (3)
238-240: Well-structured documentation addition!The introduction clearly explains the purpose and scope of the
metadata.lockedfeature. The documentation follows the established pattern of the file and integrates seamlessly with the existing content.
242-244: Important state management clarification!The info note effectively prevents potential misunderstandings about the feature's impact on Terraform state. This is crucial for users to understand the boundaries of the locking mechanism.
248-256: Excellent example implementation!The example effectively demonstrates the feature using a real-world scenario (production database) that immediately communicates the value proposition to users.
tests/fixtures/scenarios/metadata/atmos.yaml (3)
1-2: LGTM! Base path configuration is clear and concise.
19-21: Strong logging configuration, commander!The log settings are well-chosen for testing purposes. Directing logs to stderr with Info level will help track the component locking behavior effectively.
1-21: Consider schema validation strategy.Based on the past discussions and learnings, there are two paths forward for schema validation:
- Wait for the embedded JSON Schema implementation
- Explicitly specify the schema location
What's your preference, commander? We can assist with either approach.
Would you like help implementing either:
- A temporary schema location configuration
- Integration with the upcoming embedded schema feature
🧰 Tools
🪛 yamllint (1.35.1)
[error] 10-10: trailing spaces
(trailing-spaces)
internal/exec/utils.go (2)
156-158: Clean implementation of component locking state!The addition of
componentIsLockedfollows Go's idiomatic patterns and integrates well with the existing configuration processing logic.
614-617: Verify the component lock state usage.The implementation looks good. Let's verify how this locked state is used in the codebase to ensure proper enforcement of the locking mechanism.
Run the following script to check the usage of ComponentIsLocked:
✅ Verification successful
Component lock state implementation verified and complete
The lock state is properly enforced for both Terraform and Helmfile components, blocking modification commands while allowing read-only operations. Implementation is consistent and robust across the codebase.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check how ComponentIsLocked is used to enforce component locking # Search for direct references to ComponentIsLocked echo "=== Direct references to ComponentIsLocked ===" rg -A 5 "ComponentIsLocked" # Search for potential enforcement points in Terraform and Helmfile execution echo -e "\n=== Potential enforcement in Terraform/Helmfile execution ===" rg -A 10 "ExecuteTerraform|ExecuteHelmfile"Length of output: 17806
|
💥 This pull request now has conflicts. Could you fix it @milldr? 🙏 |
what
metadata.lockedwith componentstests/test_cases.yaml-->tests/test-cases/*.yamlwhy
metadata.lockedparameter prevents changes to a component while still allowing read operations. When a component is locked, operations that would modify infrastructure (liketerraform apply) are blocked, while read-only operations (liketerraform plan) remain available. By default, components are unlocked. Settingmetadata.lockedtotrueprevents any change operations.references
Summary by CodeRabbit
Release Notes
New Features
Documentation
Improvements
Test Cases