chore(deps): update terraform utils to v2 (release/v1) by renovate[bot] · Pull Request #112 · cloudposse/terraform-yaml-stack-config

renovate · 2026-02-20T22:51:45Z

This PR contains the following updates:

Package	Type	Update	Change
utils (source)	required_provider	major	`>= 1.7.1, < 2.0.0` → `< 3.0.0`

Release Notes

cloudposse/terraform-provider-utils (utils)

`v2.5.0`

Compare Source

Update Atmos to v1.211.0 with base path fallback fix for CI without .git @aknysh (#538)

what

Update Atmos dependency from v1.210.1 to v1.211.0
Update all indirect Go dependencies to latest versions
Add fix documentation for the base path resolution change

why

Atmos v1.211.0 fixes base path resolution when ATMOS_BASE_PATH is set to a relative path on CI workers (e.g., Spacelift) that lack a .git directory
The v1.210.1 fix added os.Stat + CWD fallback to tryResolveWithGitRoot, but missed the same fix in tryResolveWithConfigPath — when getGitRootOrEmpty() returns "" (no .git), the code fell through to tryResolveWithConfigPath which unconditionally joined with the config dir, producing wrong paths
The fix adds source-aware fallback ordering: runtime sources (env var, CLI flag, provider param) try CWD first, config sources (base_path in atmos.yaml) try config dir first
All modified Atmos functions are unexported — no breaking changes to the provider's public API
No provider code changes needed, only the dependency version bump

references

Atmos PR: cloudposse/atmos#2236
Atmos Release: https://github.com/cloudposse/atmos/releases/tag/v1.211.0
Previous fix: cloudposse/atmos#2215
Fix documentation: docs/fixes/2026-03-24-base-path-fallback-without-git-root.md

`v2.4.0`

Compare Source

feat: add process_templates and process_yaml_functions options to utils_component_config @Benbentwo (#535)

Summary

Add process_templates and process_yaml_functions optional boolean attributes to the utils_component_config data source, both defaulting to false
Replace the hardcoded WithProcessTemplates(false) / WithProcessYamlFunctions(false) calls with user-configurable values read from the schema
Support ATMOS_PROCESS_TEMPLATES and ATMOS_PROCESS_FUNCTIONS environment variables as defaults, enabling test environments and CI pipelines to toggle processing globally without changing Terraform code
Update example usage and docs to show the new attributes and env var support

Problem

In v2.1.0, template and YAML function processing was unconditionally disabled in utils_component_config to fix a critical ETXTBSY crash caused by !terraform.output YAML tags spawning child terraform init processes inside the provider plugin.

However, this broke a common pattern where component backend configs use Go templates like {{ .component }} and {{ getenv "..." }}. When utils_component_config returns unresolved template strings in the backend config, the terraform_remote_state data source receives literal template strings as S3 key paths and fails to find state files.

Solution

Schema Attributes (per-data-source control)

Add two new optional boolean attributes to the utils_component_config data source:

Attribute	Type	Default	Description
`process_templates`	`bool`	`false`	Enable Go template processing (Gomplate/Sprig/Atmos functions)
`process_yaml_functions`	`bool`	`false`	Enable YAML function processing (`!terraform.output`, etc.)

Both default to false, preserving the crash fix and full backwards compatibility.

Environment Variable Defaults (global control)

The following environment variables can be used to set defaults globally:

Environment Variable	Controls	Accepted Values
`ATMOS_PROCESS_TEMPLATES`	`process_templates` default	`true`/`1`/`yes` or `false`/`0`/`no`
`ATMOS_PROCESS_FUNCTIONS`	`process_yaml_functions` default	`true`/`1`/`yes` or `false`/`0`/`no`

This allows test environments and CI pipelines to enable processing globally without modifying any Terraform code. The schema attribute always takes precedence when explicitly set.

Test plan

Verify go build ./... succeeds
Verify that omitting both attributes preserves current behavior (both default to false)
Verify that ATMOS_PROCESS_TEMPLATES=true enables template processing when attribute is not set
Verify that ATMOS_PROCESS_FUNCTIONS=true enables YAML function processing when attribute is not set
Verify that an explicit process_templates = false overrides ATMOS_PROCESS_TEMPLATES=true

🤖 Generated with Claude Code

`v2.3.0`

Compare Source

Minor changes to cut new release v2 @goruha (#534)

what

Minor changes
Remove manual release creation workflow

why

Cut a new release automatically cause v2.2.0 binaries failed to pass the integrity hash sum check
A new release should be created automatically with org-defined workflows.

`v2.2.0`

Compare Source

Update Atmos to v1.210.1 with base path resolution fix @aknysh (#532)

what

Update Atmos from v1.209.0 to v1.210.1
Pick up base path resolution fix for ATMOS_BASE_PATH and --base-path / atmos_base_path with relative paths
Add 4 new tests to verify the new path resolution does not break provider behavior
Add fix documentation in docs/fixes/

why

Atmos v1.210.1 (cloudposse/atmos#2215) fixes failed to find import errors when ATMOS_BASE_PATH env var (or --base-path flag / atmos_base_path provider parameter) is set to a relative path like .terraform/modules/monorepo. Previously, resolveAbsolutePath() routed simple relative paths through git root discovery, which produced incorrect paths when CWD differed from the git root.

What changed in Atmos v1.210.1

4-category path classification:

Category	Pattern	Resolution
Empty	`""`, unset	Git root -> config dir -> CWD (smart default)
Dot	`"."`, `"./foo"`, `".."`, `"../foo"`	Source-dependent anchor (see below)
Bare	`"foo"`, `"foo/bar"`, `".terraform/..."`	Git root search with `os.Stat` fallback to CWD
Absolute	`"/abs/path"`	Pass through unchanged

Source-aware resolution (BasePathSource):

Runtime sources (env var ATMOS_BASE_PATH, CLI flag --base-path, provider param atmos_base_path): dot-prefixed paths resolve relative to CWD (shell convention)
Config source (base_path in atmos.yaml): dot-prefixed paths resolve relative to the directory containing atmos.yaml (config-file convention)

Git root fallback with os.Stat validation:

tryResolveWithGitRoot() now validates the git-root-joined path with os.Stat. If the path doesn't exist at git root but does exist relative to CWD, it falls back to the CWD-relative path. This is strictly additive — if the git-root path exists, behavior is identical to before.

Impact on the provider

Scenario-by-scenario analysis:

Scenario	Code Path	Verdict
Empty `atmos_base_path` (default)	Early return at line 297, no new code reached	SAFE — identical to previous behavior
`ATMOS_BASE_PATH=.terraform/modules/monorepo` (bare path)	`tryResolveWithGitRoot` → `os.Stat` fallback to CWD	FIXED — previously failed
`ATMOS_BASE_PATH=./.terraform/modules/monorepo` (dot-prefixed)	`resolveDotPrefixPath` → CWD-relative (runtime source)	SAFE — direct CWD resolution
Config file `base_path: "../../examples/tests"` (test fixture)	`resolveDotPrefixPath` → config-dir-relative	SAFE — no behavioral change
Empty `base_path` + subdirectory (v1.202.0 feature)	Early return at line 297 with git root	SAFE — preserved

Risk assessment:

Path Type	Before (v1.209.0)	After (v1.210.1)	Breaking?
Empty `""`	Git root -> config dir -> CWD	Same	No
Absolute `/abs/path`	Pass through	Same	No
Bare `"foo/bar"`	Git root search (no fallback)	Git root search + `os.Stat` fallback to CWD	No (safer)
Dot `"./foo"`	Resolved relative to config dir	Resolved relative to CWD (runtime source)	No (fix)
Relative `"../../path"`	Resolved relative to config dir	Source-dependent (CWD for runtime, config dir for yaml)	No (fix)

New tests

Test	What It Verifies
`TestComponentProcessorWithEmptyBasePath`	Empty `atmosBasePath` (default provider behavior) returns correct results
`TestComponentProcessorFromContextWithEmptyBasePath`	Empty `atmosBasePath` via `ProcessComponentFromContext` returns correct results
`TestComponentProcessorWithRelativeBasePath`	Relative `base_path` in `atmos.yaml` still works after path resolution changes
`TestComponentProcessorWithProcessingDisabledAndEmptyPath`	Both processing disabled + empty base path (actual provider mode) returns valid config

Test results

All 7 test packages pass (15 existing + 4 new tests) with zero regressions:

ok  github.com/cloudposse/terraform-provider-utils/internal/component  4.576s
ok  github.com/cloudposse/terraform-provider-utils/internal/convert    2.203s
ok  github.com/cloudposse/terraform-provider-utils/internal/describe   3.554s
ok  github.com/cloudposse/terraform-provider-utils/internal/merge      1.664s
ok  github.com/cloudposse/terraform-provider-utils/internal/provider   5.392s
ok  github.com/cloudposse/terraform-provider-utils/internal/spacelift  1.327s
ok  github.com/cloudposse/terraform-provider-utils/internal/stack      6.467s

references

Atmos PR: cloudposse/atmos#2215
Related issue: cloudposse/atmos#2183
Fix doc: docs/fixes/2026-03-18-base-path-resolution-for-relative-paths.md

Set GO_RELEASER_TARGET_COMMITISH in manual release workflow @aknysh (#531)

what

Set GO_RELEASER_TARGET_COMMITISH: main env var for the GoReleaser step

why

GoReleaser checks out at the tag (detached HEAD), so {{ .Branch }} resolves to HEAD
The .goreleaser.yml uses GO_RELEASER_TARGET_COMMITISH as target_commitish for the GitHub release, falling back to {{ .Branch }}
GitHub API rejects HEAD as an invalid target_commitish, causing: POST .../releases: 422 Validation Failed [{Resource:Release Field:target_commitish Code:invalid}]
The shared auto-release workflow sets this env var — our manual workflow was missing it

references

Failed workflow run: https://github.com/cloudposse/terraform-provider-utils/actions/workflows/manual-release.yml
PR #530, PR #529

Fix goreleaser dirty git state in manual release workflow @aknysh (#530)

what

Copy .goreleaser.yml to /tmp/ and run sed on the copy instead of modifying the repo file
Pass --config /tmp/.goreleaser-patched.yml to GoReleaser

why

The sed command that replaces {{ .Env.ARCHIVES_FORMAT }} was modifying .goreleaser.yml in-place, causing GoReleaser to fail with git is in a dirty state
The shared auto-release workflow avoids this by copying the config to a separate directory before patching — this follows the same pattern

references

Failed workflow run: https://github.com/cloudposse/terraform-provider-utils/actions/workflows/manual-release.yml
PR #529

Fix manual release workflow: patch goreleaser config and bump timeout @aknysh (#529)

what

Add a sed step to replace {{ .Env.ARCHIVES_FORMAT }} with zip in .goreleaser.yml before GoReleaser runs
Bump job timeout from 30m to 45m

why

GoReleaser v1 does not expand {{ .Env.ARCHIVES_FORMAT }} in the archives.format field, causing invalid archive format error
The shared auto-release workflow (shared-go-auto-release.yml) handles this with the same sed approach
The build took 28m33s, which is dangerously close to the 30m timeout

references

Manual release workflow PR: #528
Failed workflow run: https://github.com/cloudposse/terraform-provider-utils/actions/runs/22971544802

Add manual release workflow for arbitrary tags @aknysh (#528)

what

Add a new workflow_dispatch workflow (.github/workflows/manual-release.yml) that allows manually triggering a release for any existing git tag
Supports building binaries, GPG signing, and publishing via GoReleaser
Includes a make_latest option to control whether the release is marked as "Latest"

why

The auto-release workflow (shared-go-auto-release.yml) always bumps from the highest semver tag, which produces v2.x releases
We need to create v1.x releases (e.g. v1.32.0) for downstream remote-state modules that pin the provider to < 2
This workflow enables creating properly signed releases for any tag without modifying the existing auto-release pipeline

references

v2.1.0 release was auto-created when we needed v1.32.0: https://github.com/cloudposse/terraform-provider-utils/releases/tag/v2.1.0

`v2.1.0`

Compare Source

Update Atmos to 1.209.0 @aknysh (#527)

what

Update embedded Atmos library from v1.207.0 to v1.209.0
Disable template and YAML function processing in the provider by passing WithProcessTemplates(false) and WithProcessYamlFunctions(false) to both ProcessComponentInStack and ProcessComponentFromContext
Update all Go dependencies to latest versions (terraform-plugin-sdk/v2 v2.40.0, terraform-plugin-go v0.31.0, etc.)
Add 4 new tests verifying the provider works correctly with processing disabled
Add fix documentation with v1 backward compatibility analysis

why

Fix ETXTBSY crash on Linux: When stack YAML contains !terraform.output tags, the provider (since atmos v1.207.0) eagerly resolves them by spawning child terraform init processes inside the provider plugin. These child processes conflict with the parent OpenTofu process's plugin cache, causing "text file busy" errors on Linux.
Restore v1.31.0 behavior: In v1.31.0 (atmos v1.189.0), templates and YAML functions were not resolved — they were treated as opaque strings. The v2.0.0 upgrade introduced eager resolution by hardcoding both flags to true. This fix explicitly disables both, restoring the original behavior.
Provider doesn't need resolved values: The utils_component_config data source only needs backend config, workspace, and vars — not resolved template expressions or !terraform.output values.
Safe as v1 minor release: The Terraform provider schema is unchanged, processing behavior matches v1.31.0, all existing tests pass, and the provider is a compiled binary (Go API changes are internal implementation details).

references

Atmos PR exposing functional options: cloudposse/atmos#2161
Concurrent ReadDataSource serialization: #523
Atmos version mismatch plugin crash fix: #522
Fix documentation: docs/fixes/2026-03-09-disable-yaml-function-resolution-in-provider.md

`v2.0.2`

Compare Source

🚀 Enhancements

Delete .goreleaser.yml @goruha (#525)

what

Delete .goreleaser.yml

why

We made the changes in org wide release config https://github.com/cloudposse/terraform-provider-utils/pull/523

`v2.0.0`

Compare Source

Update Atmos to v1.207.0 — fix plugin crash on newer atmos.yaml configs @aknysh (#522)

what

Update embedded Atmos dependency from v1.189.0 to v1.207.0
Fix critical data "utils_component_config" plugin crash ("Plugin did not respond") that occurs when the provider's embedded Atmos version encounters newer atmos.yaml features (stores, hooks, templates.settings.gomplate)
Update import path from deleted pkg/component to restored pkg/describe for ProcessComponentInStack and ProcessComponentFromContext
Adapt all data source call sites to Atmos v1.207.0 API changes:
- Add *AtmosConfiguration parameter to MergeWithOptions calls (deep_merge_json, deep_merge_yaml)
- Add ansibleComponentsBasePath parameter to CreateSpaceliftStacks and ProcessYAMLConfigFiles calls
- Fix SliceOfInterfacesToSliceOfStrings to handle single return value
Add 19 new tests covering API compatibility and edge cases

why

Critical bug: The cloudposse/utils provider v1.31.0 embeds Atmos v1.189.0. When users run Atmos CLI v1.200+ and their atmos.yaml / stack files contain features that didn't exist in v1.189.0 (e.g. stores block, hooks with store-outputs, templates.settings.gomplate, !terraform.state YAML tags), the provider panics during cfg.InitCliConfig(), killing the gRPC plugin process. This blocks all components using cloudposse/stack-config/yaml//modules/remote-state (56+ components in a typical infrastructure repo)
Deleted API: In Atmos v1.201.0, pkg/component/component_processor.go was deleted entirely (PR #1774). The two public functions the provider depends on (ProcessComponentInStack, ProcessComponentFromContext) were moved to internal/exec (not importable). In Atmos v1.207.0, these functions were restored as public API in pkg/describe/component_processor.go
Forward compatibility: Updating to v1.207.0 ensures the provider can parse atmos.yaml files that use all current Atmos features without panicking

references

See docs/fixes/2026-02-19-atmos-version-mismatch-plugin-crash.md for full root cause analysis, call chain, and scope of impact
Atmos PR #1774 — "Path-based component resolution for all commands" (deleted pkg/component)
Atmos v1.207.0 — restored ProcessComponentInStack and ProcessComponentFromContext in pkg/describe

Use atmos instead of makefile @goruha (#501)

what

Use atmos instead of makefile

why

build-harness deprecated. Use atmos instead

Fix release workflow @goruha (#499)

what

Fix release workflow

why

Release workflow put's comments into PRs that it is released. Permissions required

references

https://github.com/cloudposse/terraform-provider-utils/actions/runs/17445640722

🤖 Automatic Updates

Added go linting @[dependabot[bot]](https://redirect.github.com/apps/dependabot) (#493)

what

Added go linting

why

Port go linting from atmos

References

https://linear.app/cloudposse/issue/DEV-3115/consistent-lintcoverage-checks-in-go-repos

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

mergify · 2026-02-20T22:52:21Z

/terratest

chore(deps): update terraform utils to v2

adee520

renovate Bot added the auto-update This PR was automatically generated label Feb 20, 2026

renovate Bot requested review from a team as code owners February 20, 2026 22:51

renovate Bot requested review from Nuru (Nuru) and Joe Niland (joe-niland) and removed request for a team February 20, 2026 22:51

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

chore(deps): update terraform utils to v2 (release/v1)#112

chore(deps): update terraform utils to v2 (release/v1)#112
renovate[bot] wants to merge 1 commit into
release/v1from
renovate/release/v1-utils-2.x

renovate Bot commented Feb 20, 2026 •

edited

Loading

Uh oh!

mergify Bot commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Uh oh!

Conversation

renovate Bot commented Feb 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Release Notes

v2.5.0

what

why

references

v2.4.0

Summary

Problem

Solution

Schema Attributes (per-data-source control)

Environment Variable Defaults (global control)

Test plan

v2.3.0

what

why

v2.2.0

what

why

What changed in Atmos v1.210.1

Impact on the provider

New tests

Test results

references

what

why

references

what

why

references

what

why

references

what

why

references

v2.1.0

what

why

references

v2.0.2

🚀 Enhancements

what

why

v2.0.0

what

why

references

what

why

what

why

references

🤖 Automatic Updates

what

why

References

Configuration

Uh oh!

mergify Bot commented Feb 20, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate Bot commented Feb 20, 2026 •

edited

Loading

`v2.5.0`

`v2.4.0`

`v2.3.0`

`v2.2.0`

`v2.1.0`

`v2.0.2`

`v2.0.0`