Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .github/workflows/diff_shades_comment.yml
Original file line number Diff line number Diff line change
Expand Up @@ -33,7 +33,7 @@ jobs:
- name: Try to find pre-existing PR comment
if: steps.metadata.outputs.needs-comment == 'true'
id: find-comment
uses: peter-evans/find-comment@f4499a714d59013c74a08789b48abe4b704364a0
uses: peter-evans/find-comment@81e2da3af01c92f83cb927cf3ace0e085617c556
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we or should we move to release tags? Anyone remember why we on commit hashes?

https://github.com/peter-evans/find-comment/releases/tag/v2.2.0

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Security, SHAs are immutable so even if some bad actor gains access and updates a tag to contain malicious code, it would take an upgrade on our side to pull it in. It doesn't really make any sense though since it's unlikely we'd do an comprehensive audit of the line changes committed since the old version.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems safer to keep using commit hashes since an attacker could modify the tag, and this would take effect immediately unlike a release.

with:
issue-number: ${{ steps.metadata.outputs.pr-number }}
comment-author: "github-actions[bot]"
Expand Down