feat(comment): optionally disable comment

[FalcoSuessgott]

This action currently attempts to overwrite / recreate any previous comments. While this approach is useful for most setups, it leads to race conditions when this actions is being used in a matrix - where one job overwrites the comment of a previous job.

This PR introduces a new boolean argument post-comment that if disabled, skips posting the TF diff comment.
Users can then instead use the output of the action and implement their own commenting logic:

This approach could also be used to allow posting all diffs in one comment (#535):

Example:

jobs:
  tf-plan:
    strategy:
      fail-fast: false
      matrix:
        include:
          - cluster: dev
            account_id: "1234"
          - cluster: prod
            account_id: "56789"
  steps:
      - id: terraform-plan
        uses: op5dev/tf-via-pr@v13
        with:
          working-directory: infra
          post-comment: false

      - name: Post Terraform plan comment
        env:
          GITHUB_TOKEN: ${{ steps.app-token.outputs.token }}
          COMMENT_BODY: ${{ steps.terraform-plan.outputs.comment-body }}
          COMMENT_TITLE: ${{ github.workflow }} / ${{ matrix.cluster }}
        run: |
          comment_file="$(mktemp)"
          printf '## %s\n\n%s\n' \
            "${COMMENT_TITLE}" \
            "${COMMENT_BODY}" > "${comment_file}"

          gh pr comment "${{ github.event.number }}" \
            --repo "${{ github.repository }}" \
            --body-file "${comment_file}"

result:

Terraform Infrastructure CI / prod

terraform plan -chdir=infra -var-file=vars/default.tfvars -var-file=clusters/prod.tfvars
Diff of 3 changes.
Plan: 0 to add, 3 to change, 0 to destroy.
By @FalcoSuessgott at 2026-03-24T05:19:41Z.

Terraform Infrastructure CI / dev

terraform plan -chdir=infra -var-file=vars/default.tfvars -var-file=clusters/dev.tfvars
Diff of 4 changes.
Plan: 0 to add, 4 to change, 0 to destroy.
By @FalcoSuessgott at 2026-03-24T05:19:41Z .

[FalcoSuessgott]

alternatively, we could update comment-method to accept like none to skip comment creation

[ArkShocer]

Can you show how you tried it with the normal commenting enabled in your matrix job? Or is the example yaml above already the one with the issue? We are using the action in pretty much every repository with matrix and have no issues at all.

[FalcoSuessgott]

Can you show how you tried it with the normal commenting enabled in your matrix job? Or is the example yaml above already the one with the issue? We are using the action in pretty much every repository with matrix and have no issues at all.

No the example above is from the approach introduced in this PR (wait for all matrix jobs to finish and then post the plans in separate comments).

IIRC I noticed that this GHA would overwrite existing/previous comments (so that one matrix job would overwrite the plan comment of another matrix job), so I wasn't able to see all plans from my matrix jobs.

But if you got it work, then there might have been another problem on my side .. Ive migrated to Atlantis, so can't investigate further.

Regardless, perhaps this PR still makes sense for some custom setups.

[rdhar]

@FalcoSuessgott Thanks for taking the time to raise this PR, much appreciated!

As @ArkShocer mentioned, I'm also unable to follow/understand the intent here. The PR title states "optionally disable comment", which is already documented as a supported feature with comment-pr: never (source). The proposed change appears to replicate that existing behaviour, unless I'm mistaken?

With that said, I'm glad you found Atlantis: it's a bulletproof, CNCF-backed-project and I'm a long-time user. While setting up Atlantis for several teams/projects over the years, I found it fell short of: GitHub native features (e.g., environment deployment protection, merge queues with required checks); modern security practices (relying on static credentials for authentication rather than short-lived OpenID Connect tokens); and, complicated audit trail (since you're responsible for hosting a persistent compute instance as well as maintaining least-privilege access to sensitive plans).

TF-via-PR came to be as a lightweight alternative which makes the most of GitHub's built-in features (e.g., ephemeral runners with zero-overhead for hosting or maintaining infrastructure beyond a state backend). Not too long ago, gave a talk on this very topic, if you're interested.