feat: don't leave a comment when there are no changes

[leetrout]

• Adds hide-no-changes-pr-comment input (default: false) to hide the PR comment when there are no
  module changes and no legacy tags/releases pending deletion
  • The comment is still posted (preserving the PR_RELEASE_MARKER for idempotency checks) but minimized via GitHub's GraphQL API so it appears collapsed by default
  • When there are changes to report, comments always post visibly regardless of this flag

Behavior

Scenario	hide-no-changes-pr-comment: false (default)	hide-no-changes-pr-comment: true
Modules need release	✅ posts comment visibly	✅ posts comment visibly
Legacy tags/releases to delete	✅ posts comment visibly	✅ posts comment visibly
No changes, nothing to delete	✅ posts comment visibly	🔇 posts comment hidden/minimized

AI Disclosure

Used claude for these changes.

[leetrout]

@virgofx thoughts? 😎

[virgofx]

Hey @leetrout , Thanks for this, the feature makes a lot of sense.

A couple of thoughts:

1. Comment visibility: hidden vs. removed

Would you be open to having the "no changes" comment still posted but as a hidden/minimized comment instead of fully suppressed? That way it shows up like: (Hidden > 'Resolved') mode

The reason I bring this up is there's an important idempotency edge case we need to preserve. On merge, we check for the presence of a PR_RELEASE_MARKER in PR comments to prevent duplicate releases on re-runs (see the guard in main.ts). If we fully skip the comment, we need to be careful that the marker logic still works correctly for all failure/retry modes. If we hide rather than skip, we can sidestep that edge case entirely since the marker would still be present in the comment body. It's likely only an issue for the PR-post-build comment (merge-to-main) but will require some additional checks if we fully delete comment.

The other reason - Someone accidently enables this and then is wondering where the comment is. At least here there's a fallback where it could be expanded manually but the out of box experience (which I believe you're trying to streamline) is still achieved?

2. Input naming

I think the input name could be a bit more descriptive. Some alternatives:

• suppress-no-changes-comment — clearer intent ("suppress" vs "disable")
• skip-empty-pr-comment — shorter, focuses on what it does
• hide-no-changes-pr-comment — if we go with the hidden/minimized approach
• quiet-when-no-changes — concise, describes the behavior

I'm leaning toward hide-no-changes-pr-comment or suppress-no-changes-comment depending on which approach we go with.

What do you think?

--

If you're onboard with the slight change, I'm happy to take this branch and modify to get finalized if that works? Alternatively, I can spin new branch off and close this to preserve yours. LMK

[leetrout]

@virgofx all makes sense to me! sorry for the late reply 😞

First: Yes a minimized comment is certainly a great improvement for our eyeballs rushing through PRs!! 😂 🙈

Second: Some more background: we went down this path because we assign our entire team to reviews via the @group tagging. So then for ~95% of our infra PRs we are sending extra emails to them generating more noise in the inboxes due to the (for us) unused comments and it clutters up the view with atlantis as well.

I had the clanker true things up to your comments and catchup to main. The matrix of statistical weights also offered this opinion:

The idempotency guard in main.ts:197 checks for PR_RELEASE_MARKER, which is only ever written by addPostReleaseComment on a merge event. Skipping the no-changes addReleasePlanComment comment has zero effect on the idempotency guard

[qbedard]

Is a PR comment the only way to track this state? This method seems brittle. I'm pretty sure it will also fail on high-traffic monorepos due to rate-limiting (a problem I've run into in the past with posting PR comments).

Couldn't it guard against the target cases in other ways? GitHub Actions concurrency groups? Creating a cache entry?

[virgofx]

Hi @leetrout @qbedard - Sorry for the delay here. I'm working on a new PR, incorporating @leetrout 's changes as well as adding some improved functionality to remove the 1 idempotency marker on post-release to make it more robust. Will keep you all posted.