Per docs, you can increase development velocity with a merge queue for pull requests in your repository.
To do so, you must use the merge_group event to trigger your GitHub Actions workflow when a pull request is added to a merge queue.
Expected behavior
When a given workflow with on.pull_request and on.merge_group event triggers is merged, the PR gets added to the merge where status checks are carried out.
TF-via-PR should demonstrate compatibility with the merge_group event trigger by posting relevant TF command outputs as comments on the source PR.
The success/failure of provisioning TF should be captured by associated status checks.
Additional context
This is inspired by #238 which requests support for workflow_dispatch event trigger.
With the launch of OpenTofu fork, I'd like to support OpenTofu as a first-class IaC provisioning tool, just like Hashicorp's Terraform.
Describe alternatives you've considered
While we await (pre-)releases to become available, a serviceable workaround has been shared by @zimeg (from Slack) to download, install and initialize OpenTofu CLI in 3 GitHub Actions steps.
Ensure that this GitHub Action has full compatibility with push event triggered workflows, just as done with pull_request.types[closed] trigger for merging PRs.
I would love to try this tool with my current Terragrunt setup. However, I don't see how I could integrate it with your tool.
Describe the solution you'd like
Besides installing and setting up Terraform, I wish to setup Terragrunt and have commands such as apply-all, plan-all, init-all, delete-all and others to be encompassed by this workflow.
Our current Terraform IaC implementation enables deployment of multiple environments via GitHub Actions, allowing directory-based environment isolation and management of multiple backends/workspaces from a single repository.
We'd like to extend this to allow for management of multiple environments spanning different regions and/or AWS accounts to support the tiered needs of various sized clients with greater flexibility.
Specific Problems
Workflow
Our existing method relies on pull request labels to trigger the appropriate workflow for the environment(s) being deployed. While straightforward, this is too simple to target provisioning of specific resources.
It's also limited in terms of allowing CLI-based inputs, including: var-file, backend-config, and auto-approve to name a few.
By default, IaC is only provisioned on merge of the PR. Not ideal for validating changes since some plans can pass review but fail to apply due to unforeseen constraints (e.g., lack of subnet availability).