[mario-campos]

This PR adds a PR check for non-release/mergeback/update-bundle PRs. The check posts a sticky PR comment if CHANGELOG.md has been modified in the PR, warning the author to instead direct their change to a change-note.

Testing

In order to test this Action and its script, I forked this repository at dsp-testing/mario-campos-post-comment-test and modified the CHANGELOG.md file in a PR.

In dsp-testing#2, a comment was successfully created.

In dsp-testing#3, I modified CHANGELOG.md to invoke the comment, and then subsequently reverted the change to successfully invoke the comment deletion.

Risk assessment

For internal use only. Please select the risk level of this change:

• Low risk: Changes are fully under feature flags, or have been fully tested and validated in pre-production environments and are highly observable, or are documentation or test only.

Which use cases does this change impact?

Workflow types:

• N/A

Products:

• N/A

Environments:

• Test repository - This change will be tested on a test repository before merging.
• Testing/None - This change does not impact any CodeQL workflows in production.

How did/will you validate this change?

• None - I am not validating these changes.

If something goes wrong after this change is released, what are the mitigation and rollback strategies?

• Development/testing only - This change cannot cause any failures in production.

How will you know if something goes wrong after this change is released?

• N/A

Are there any special considerations for merging or releasing this change?

• No special considerations - This change can be merged at any time.

Merge / deployment checklist

• Confirm this change is backwards compatible with existing workflows.
• Consider adding a changelog entry for this change.
• Confirm the readme and docs have been updated if necessary.

[mbg]

Couple of initial comments on this draft. I like that this is taking advantage of the setup that the existing fetch-base provides.

I haven't checked if the changelog-check step behaves as expected yet either. One thing I did note though related to it is that the fetch-base step is skipped if github.event.pull_request.user.login != 'dependabot[bot]'. That isn't new in this PR (and we probably shouldn't address it here), but it might be better to check github.triggering_actor instead of github.event.pull_request.user.login. The justification in the comment is that Dependabot doesn't have permission, but it is possible for us to push commits to Dependabot PR branches or re-run workflows on it.

Also agree that it would be good to not spam the comment and instead replace an existing one. It's fairly easy to do that with gh or in a script by leaving a comment (<!-- some distinct marker -->) in the comment that's posted and then looking for that.

[Copilot]

🟡 Changes recommended

Shell command substitution currently prevents warning creation, and comment lifecycle and exclusion logic need correction.

3 open findings

• Stale warning persists when changelog changes are reverted · New
• Title-only exemption suppresses warnings for ordinary pull requests · New
• Unescaped backticks trigger command substitution and fail the warning step · New

What changed in this PR

Adds a PR check that warns contributors to use change notes instead of editing CHANGELOG.md directly.

Changes:

• Detects CHANGELOG.md modifications.
• Adds a sticky warning comment with automation exclusions.
• Consolidates PR comment posting into one job.

File	Description
.github/​workflows/​pr-checks.yml	Detects changelog edits and posts PR warnings.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[mario-campos]

@copilot Are there unresolved findings?

[Copilot]

@copilot Are there unresolved findings?

Yes—one valid finding remains: the warning step is gated on changelog-changed == 'true', so if a later commit reverts the CHANGELOG.md change, the step never runs and the existing warning comment stays stale. It should also run when the file is unchanged and remove any existing marker comment. The shell backticks are escaped, and the automation exclusion checks now include branch criteria.

[Copilot]

🟢 Approval recommended

The workflow correctly handles comment creation, deduplication, cleanup, and automation exemptions.

0 open findings

3 resolved since last review

• Unescaped backticks trigger command substitution and fail the warning step
• Title-only exemption suppresses warnings for ordinary pull requests
• Stale warning persists when changelog changes are reverted

🧠 Review effort: Balanced

[mbg]

Thanks for changing this to move away from pulling in another action and also moving the step that posts or updates the comment out of other-checks and into (now) post-pr-comments.

I added a few more comments, but the main one is about avoiding more, lengthy-ish shell scripts. It shouldn't be hard to implement in TS in pr-checks and I have included some relevant pointers in my detailed comment about this.

[Copilot]

🟡 Changes recommended

Input-validation, test-coverage, link, and workflow-bootstrap issues remain unresolved.

5 open findings

• Avoid resolving the local action from the PR base SHA · New
• Reject empty or whitespace-only comment markers · New
• Validate issue numbers as complete positive integers · New
• Use a repository-qualified URL for change-note instructions · New
• Add tests for comment operation dispatch branches · New

🧠 Review effort: Balanced

[mario-campos]

Note: the failed check is expected, because it's a consequence of introducing an Action and simoultanously changing the workflow to call said Action in the PR's base ref. For this PR, it's a not possible to do both, but it shan't be a problem once merged.

[mbg]

I have added some detailed comments with some major points of feedback, but they are all broadly aligned with what we discussed elsewhere already about this script/action being too over-engineered.