devsectop / tf-via-pr Goto Github PK

Describe the bug

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

1. 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.
2. TF-via-PR should demonstrate compatibility with the merge_group event trigger by posting relevant TF command outputs as comments on the source PR.
3. 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.

Is your feature request related to a problem

N/a.

Describe the solution you'd like

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.

- name: Download the tofu source
  uses: actions/checkout@v4
  with:
    repository: opentofu/opentofu
    path: opentofu

- name: Install tofu tooling
  uses: actions/setup-go@v4
  with:
    go-version-file: opentofu/go.mod
    cache-dependency-path: opentofu/go.sum

- name: Prepare the tofu command
  working-directory: opentofu
  run: |
    go build -ldflags "-w -s -X 'github.com/opentofu/opentofu/version.dev=no'" -o bin/tofu .
    echo $(pwd)/bin >> $GITHUB_PATH

Additional context

Issue opentofu/opentofu#556 has been raised in order to deliver a more "drop-in replacement"-able equivalent to hashicorp/setup-terraform.

Describe the solution you'd like

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.

Additional context

Inspired in chain by #238 and #242.

Following on from #244, add workflow example to demonstrate the use-case scenario of merge_group event triggered workflow.

Describe the bug

GitHub Actions fails when the job name includes spaces or other unallowed characters.
Can be fixed by sanitizing the job name.

Screenshots

Additional context

Is your feature request related to a problem

This is in context of the so-called "GitHub Actions Worm".

Describe the solution you'd like

We want to decrease our reliance on 3rd party/upstream dependencies. where appropriate.

Describe alternatives you've considered

Potential sources:

• actions/github-script
• run: bash.

Additional context

N/a.

Is your feature request related to a problem

This is in context of the so-called "GitHub Actions Worm".

Describe the solution you'd like

We want to decrease our reliance on 3rd party/upstream dependencies. where appropriate.

Describe alternatives you've considered

Potential sources:

• actions/github-script
• run: bash.

Additional context

N/a.

Is your feature request related to a problem

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.

Describe alternatives you've considered

I am considering using the Terragrunt github actions workflow, but it does not support triggering actions via comments. https://github.com/gruntwork-io/terragrunt-action

Additional context

N/A

TL;DR

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).

Multi-Region/Account

• Separated backend.tfvars is finicky for local Terraform usage as we have to specify chdir and backend-config each time since Terraform does not support variable interpolation in backend configuration.
• Directory naming convention, or lack thereof, is not conducive to provisioning of resources across regions or accounts without a structured approach.
• Provisioning is tied to a single account by long-lived credentials to authenticate AWS access via access and secret keys.

Proposed Solution

Instead of labels, use pull request comments to trigger workflows.

• Allows for more granular control over the provisioning of IaC, similar to local CLI usage or Atlantis runner.
• Addresses validation of IaC before merge by applying a plan during the pull request workflow.
• Create deployment markers automatically when a terraform plan is applied.

Describe the bug

Getting this error when triggering the workflow manually from a workflow_dispatch event.

Screenshots

Additional context

Is your feature request related to a problem

At the moment, the only way this workflow can be triggered initially is via a comment starting with -terraform.

Describe the solution you'd like

I'd like this triggering keyword to be user-configurable. E.g., /terraform, -tf, etc.

Describe alternatives you've considered

N/a.

Additional context

N/a.

Is your feature request related to a problem

This is in context of the so-called "GitHub Actions Worm".

Describe the solution you'd like

We want to decrease our reliance on 3rd party/upstream dependencies. where appropriate.

Describe alternatives you've considered

Potential sources:

• actions/github-script
• run: bash.

Additional context

N/a.