Feature: Implement "Sticky" Comments (Idempotency) to Reduce PR Noise

Labels: enhancement, ux, good-first-issue

User Story

As a DevOps Engineer maintaining CI/CD pipelines I want the SARIF to Comment action to update an existing report on a Pull Request rather than creating a new comment every time the workflow runs So that the PR timeline remains clean, readable, and focused on the latest security status without scrolling through outdated reports.

Context

Currently, every time this action runs (e.g., on every commit to a PR), it appends a new comment. On active PRs, this results in "Wall of Text" spam, causing developers to ignore the security findings entirely. We want to move to a "Sticky Comment" model where the bot manages a single source of truth per report.

Architecture

Wrapper + Internalized Logic

Method

Hidden HTML Marker

Constraint

Backward Compatibility

Acceptance Criteria

• Marker Implementation: The action must append a hidden HTML comment (e.g., ``) to the generated Markdown body.
• Check Before Post: Before posting, the action must search existing comments on the PR for this specific marker.
• Update vs. Create Logic:
  • If the marker is found: Update the body of that specific comment with the new scan results.
  • If the marker is not found: Create a brand new comment.
• Multi-Report Support: The marker should be unique based on the provided title or a new id input. This ensures that if a user runs a "Backend Scan" and a "Frontend Scan" in the same PR, they update two separate comments rather than overwriting each other.
  • Example Marker: ``
• Fail-Open: If the logic to find/update comments fails (e.g., API rate limits), the action should fall back to creating a new comment so the security data is not lost.

Technical Implementation Notes (Developer Guide) (optional)

• API Usage: Use octokit.rest.issues.listComments (with pagination) to find the comment, and octokit.rest.issues.updateComment to patch it.
• Author Safety: Do not strictly rely on comment.user.login === 'github-actions[bot]' as this fails for Enterprise/PAT users. Rely primarily on the presence of the unique HTML marker in comment.body.
• Reference: This logic mirrors the behavior of peter-evans/create-or-update-comment but internalizes it to keep our action a "one-stop shop."

Definition of Done

1. Unit tests covering the "Create" vs "Update" logic paths.
2. Contract tests
3. Integration test
4. Manual verification on a PR:

• Run 1: Comment appears.
• Run 2: Comment is updated (timestamp changes to "edited").
• Run 3 (different title): Second comment appears.

References

• #331