v1.5.1

Issues | Pull Requests | v1.5.0...v1.5.1 | Base revision

Fix

#1665 Use regular expression to handle follow up pr targets @tk3fftk

v1.5.0

Issues | Pull Requests | v1.4.0...v1.5.0 | Base revision

Features

#1634 #1643 Add optional settings gcp_remote_backend_service_account and gcp_remote_backend_workload_identity_provider to configure a Google Cloud Service Account for Terraform Remote Backend @rochana-atapattu

By default, gcp_service_account and gcp_workload_identity_provider are used, but you can use a different service account for
GCS Backend.
The environment variable GOOGLE_BACKEND_CREDENTIALS is set.

Fixes

#1660 #1661 follow up pr: Fix a bug that a target of a follow up pull request can't be extracted from a pull request description properly if the newline code isn't \n but \r\n somehow @cappyzawa

https://suzuki-shunsuke.github.io/tfaction/docs/feature/follow-up-pr

When an apply workflow fails tfaction creates a follow up pull request.
tfaction embeds the target name in the pull request description.

This release fixes a bug that the target embedded in the pull request description can't be extracted properly if the newline code isn't \n but \r\n somehow.

v1.4.0

Issues | Pull Requests | v1.3.2...v1.4.0 | Base revision

Features

#1325 #1611 setup: Support setting google-github-actions/auth's access_token_scopes

This update adds the setting gcp_access_token_scopes to enable tfaction to set google-github-actions/auth's access_token_scopes.

The format is same with google-github-actions/auth's access_token_scopes.

tfaction-root.yaml

e.g.

targets:
- working_directory: gcp/
  target: gcp/
  terraform_plan_config:
    gcp_access_token_scopes: 'https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/apps.groups.settings, https://www.googleapis.com/auth/admin.directory.group'

tfaction.yaml

terraform_plan_config:
  gcp_access_token_scopes: 'https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/apps.groups.settings, https://www.googleapis.com/auth/admin.directory.group'

v1.4.0-1

v1.3.1...v1.4.0-1

Features

#1325 #1611 feat(setup): support setting google-github-actions/auth's access_token_scopes

v1.3.2

Issues | Pull Requests | v1.3.1...v1.3.2 | Base revision

Fixes

#1574 #1612 Improve the error message if plan_workflow_name is wrong

v1.3.1

Issues | Pull Requests | v1.3.0...v1.3.1 | Base revision

Others

#1564 #1593 export-secrets: Output secret names for troubleshooting

The action export-secrets outputs secret names passed to the action for troubleshooting.
The log is useful to check if secrets are passed to the action properly.

If secrets aren't passed properly, this isn't a bug of tfaction.
You have to check your workflow and the usage of tfaction.

#1590 #1591 Migrate Jest to Vitest @exoego

#1595 Throw an error object instead of a string

v1.3.1-1

Base revision

#1593 export-secrets: Output secret names for troubleshooting

The action export-secrets outputs secret names passed to the action for troubleshooting.
The log is useful to check if secrets are passed to the action properly.

If secrets aren't passed properly, this isn't a bug of tfaction.
You have to check your workflow and the usage of tfaction.

• #1564

#1590 #1591 Migrate Jest to Vitest @exoego

v1.3.0

Issues | Pull Requests | v1.2.3...v1.3.0 | Base revision

Features

#1528 Run CI on working directories that depend on a updated local path Module @exoego

https://suzuki-shunsuke.github.io/tfaction/docs/feature/local-path-module

By default, tfaction runs CI on only working directories where any code is updated.
This means even if a working directory depends on a local path Module out of the working directory and the module is updated, CI isn't run on the working directory.

e.g.

• A working directory A depends on local path Module B
• Module B is located out of the working directory A
• In a pull request C, working directory A isn't changed but the module B is changed
• Then CI isn't run on the working directory A by default

working directory A/
modules/
  module B

This release enables you to run CI on the working directory A too.
To do that, please update tfaction-root.yaml as the following.

tfaction-root.yaml

update_local_path_module_caller:
  enabled: true

This feature depends on terraform-config-inspect, so you have to install it.
Same with other tools, you can install terraform-config-inspect with aqua.

e.g.

packages:
  - name: hashicorp/terraform-config-inspect
    version: a34142ec2a72dd916592afd3247dd354f1cc7e5c

In that case, Go is required.

If this feature is enabled, when a module is updated in a pull request, CI is run on working directories depending on the module.
The module dependency is checked recursively.
For example, in the above case if the module B depends on a module C and module C is updated in a pull request,
CI is run on the working directory A even if the working directory A and the module B aren't updated.

🎉 New Contributors

Thank you for your contribution!

@exoego #1528

v1.2.3

Issues | Pull Requests | v1.2.2...v1.2.3 | Base revision

Bug Fixes

#1583 test-module: Fix a bug that a Module document isn't updated by terraform-docs in case of pull_request_target event
#1584 test-module: Fix a bug that a Module document isn't updated by terraform-docs properly if terraform-docs's output.file is set

v1.2.2

Issues | Pull Requests | v1.2.1...v1.2.2 | Base revision

Bug Fixes

#1578 test-module: Run terraform init to install providers and modules before running linters such as tflint

tflint expect that all referenced modules will be already installed and described in our manifest.

https://github.com/terraform-linters/tflint/blob/66c7be71b6b18bbd4cd93ce843098acd5dc74642/terraform/loader.go#L126-L141