Releases: terramate-io/terramate
Releases · terramate-io/terramate
v0.9.4
Changed
- Use terramate-io/tfjson in replacement of hashicorp/terraform-json for the JSON representation of the plan file.
v0.9.4-rc1
Changed
- Use terramate-io/tfjson in replacement of hashicorp/terraform-json for the JSON representation of the plan file.
v0.9.3
Fixed
- Fix a missing check for
GITLAB_CI
environment variable.- The previews feature can only be used in Github Actions and Gitlab CI/CD and a check for the latter was missing.
- Fix the synchronization of the GitLab Merge Request commit SHA and pushed_at.
v0.9.3-rc1
Fixed
- Fix a missing check for
GITLAB_CI
environment variable.- The previews feature can only be used in Github Actions and Gitlab CI/CD and a check for the latter was missing.
- Fix the synchronization of the GitLab Merge Request commit SHA.
v0.9.2
v0.9.1
Added
- Add cloud filters
--deployment-status=<status>
and--drift-status
to commands below:terramate list
terramate run
terramate experimental trigger
- Add support for generating files relative to working directory. Both examples below only generate files inside
some/dir
:terramate -C some/dir generate
cd some/dir && terramate generate
- Add synchronization of Gitlab Merge Request and CI/CD Metadata.
Fixed
- Fix crash when supplying a tag list with a trailing comma separator.
v0.9.1-rc1
Added
- Add cloud filters
--deployment-status=<status>
and--drift-status
to commands below:terramate list
terramate run
terramate experimental trigger
- Add support for generating files relative to working directory. Both examples below only generate files inside
some/dir
:terramate -C some/dir generate
cd some/dir && terramate generate
- Add synchronization of Gitlab Merge Request and CI/CD Metadata.
Fixed
- Fix crash when supplying a tag list with a trailing comma separator.
v0.9.0
Added
- Add support for
[for ...]
and{for ...}
expressions containing Terramate variables and functions inside thegenerate_hcl.content
block. - Add experimental support for deployment targets. This allows to keep separate stack information when the same stacks are deployed to multiple environments, i.e. production and staging.
- Can be enabled with
terramate.config.experiments = ["targets"]
andterramate.config.cloud.targets.enabled = true
. - Once enabled, commands that synchronize or read stack information to Terramate Cloud require a
--target <target_id>
parameter. These include:terramate run --sync-deployment/--sync-drift-status/--sync-preview
terramate script run
terramate run --status
terramate list --status
terramate cloud drift show
- Can be enabled with
- Add
script.lets
block for declaring variables that are local to the script. - Add
--ignore-change
flag toterramate experimental trigger
, which makes the change detection ignore the given stacks.- It inverts the default trigger behavior.
- Add
--recursive
flag toterramate experimental trigger
for triggering all child stacks of given path.
Fixed
- Fix
terramate experimental trigger --status
to respect the-C <dir>
flag.- Now using
-C <dir>
(or--chdir <dir>
) only triggers stacks inside the provided dir.
- Now using
- Fix the update of stack status to respect the configured parallelism option and only set stack status to be
running
before the command starts. - Fix
terramate experimental trigger
gives a misleading error message when a stack is not found.
Changed
- (BREAKING CHANGE) The format of the generated code may change while being still semantically the same as before. This change is marked as "breaking", because this may trigger change detection on files where the formatting changes.
v0.9.0-rc5
Fixed
- Fix the case of using Terramate with targets disabled if stacks were previously synchronized with targets enabled.
- This change is not part of v0.9.0 changelog because this addresses the issue in an unreleased feature.
v0.9.0-rc4
Added
- Add
--recursive
flag toterramate experimental trigger
for triggering all child stacks of given path.