[castillios]

Fixes #8590

What changes did you make?

Add default permissions

• Add default permissions of contents: read to pull-request-trigger.yml
• Add the following default permissions to wr-pull-request-trigger.yml:

contents: read
issues: write
pull-requests: write

Refactor workflow

• Split up linked issue checking and PR commenting functionality from pull-request-trigger.yml into the following:
  • pull-request-trigger.yml handles linked issue checking
  • wr-pull-request-trigger.yml handles PR commenting
• Refactored check-linked-issue.js into 3 main functions (downloadPRCommentArtifact, checkForLinkedIssue, postPRComment) and several helper functions
  • Implement artifacts into the pr trigger workflow to pass PR comment data between automations

Clean up

• Replaced console.log with core.info
• While creating this PR I noticed that the Post Comment logs in WR PR Trigger weren't very detailed. I updated the logging to include the PR # comments are posted to

Why did you make the changes (we will use this info to test)?

Add default permissions

• According to Will's comment we had to refactor the workflows as a workaround to GitHub's tightening security features.
• The default permissions I added differ slightly from his solution. The following lists why:
  • After testing the refactor with Will's suggested permissions and still running into errors, I updated wr-pull-request-trigger.yml to include an additional permission, pull-requests: write
  • In wr-pull-request-trigger.yml BOTH issues: write and pull-requests: write were added to allow PR commenting. Despite github docs implying that only one write permission is needed, without both permissions a 403 error will still occur: Testing log with only one write permission. I've included successful test logs using both permissions at the bottom of this PR.

Refactor workflow

• check-linked-issue.js was broken up into several functions to allow the functionality to split into two automations.

Clean up

• I replaced console.log with core.info for consistency as they are typically used as a logging tool for GHA workflows.
• Added PR #'s in WR PR Trigger logs for clarity
• Any additional commits other than the main refactor (812c9b9), updating permissions (77d3999, 4785794), replacing console.log (830112c), clean up the code and squash any errors (i.e. forgetting an await, cleaning up comments, etc).

CodeQL Alerts

After the PR has been submitted and the resulting GitHub actions/checks have been completed, developers should check the PR for CodeQL alert annotations.

Check the PR's comments. If present on your PR, the CodeQL alert looks similar as shown

Please let us know that you have checked for CodeQL alerts. Please do not dismiss alerts.

• I have checked this PR for CodeQL alerts and none were found.
• I found CodeQL alert(s), and (select one):
  • I have resolved the CodeQL alert(s) as noted
  • I believe the CodeQL alert(s) is a false positive (Merge Team will evaluate)
  • I have followed the Instructions below, but I am still stuck (Merge Team will evaluate)

Instructions for resolving CodeQL alerts

If CodeQL alert/annotations appear, refer to How to Resolve CodeQL alerts.

In general, CodeQL alerts should be resolved prior to PR reviews and merging

Screenshots of Proposed Changes To The Website (if any, please do not include screenshots of code changes)

No visual changes to the website

I tested the workflow for three different scenarios. In WR PR Trigger Log, please view "Post Comment to PR" for a detailed log:

• No linked issue: PR with comment | PR Trigger Log | WR PR Trigger Log
• Invalid linked issue: PR with comment | PR Trigger Log | WR PR Trigger Log
• Valid linked issue: PR with no comment | PR Trigger Log | WR PR Trigger Log

I later added PR #'s to WR PR Trigger's logging - Test log:

[github-actions]

Want to review this pull request? Take a look at this documentation for a step by step guide!

---

From your project repository, check out a new branch and test the changes.

git checkout -b castillios-pr-trigger-permissions-8590 gh-pages
git pull https://github.com/castillios/website.git pr-trigger-permissions-8590

[castillios]

Hi @daras-cu, while working on this solution, I modeled the refactor off of set-pr-labels.js and how it uses artifacts. Since the functions are very similar, should we consider creating an ER and making a shared module to handle artifacts?

[daras-cu]

ETA: 10/5 EOD
Availability: Sunday, evenings

[daras-cu]

@castillios I tested this in my repo and everything works as it should, great job!

• I had the same results as you when testing PRs with no linked issue, and invalid issue, and a valid issue
• The additional pull-requests: write permission is appropriate, I confirmed the workflow fails without it
• The code changes are clear and match the structure of the Set PR labels workflow files for consistency
• The 'clean up' changes improve the readability of the workflows and will help in future debugging, particularly wr-pull-request-trigger.yml
  Overall an effective solution for implementing the permissions, thanks for all the work you put in to this.

[daras-cu]

@castillios I do think a module for artifacts is a good idea, can you write an ER for it? I think it can call for two separate issues, one maybe medium or large to create the module and then use it in one of the JS files, and a second medium issue to implement the module with the other file.

[castillios]

@castillios I do think a module for artifacts is a good idea, can you write an ER for it? I think it can call for two separate issues, one maybe medium or large to create the module and then use it in one of the JS files, and a second medium issue to implement the module with the other file.

Thank you for the detailed review @daras-cu. As for the ER, I'll have that written up this week. Thanks for providing a starting point for it!

[yielderdev]

Availability: Monday 12pm-5pm, Tuesday 12pm-5pm, + intermittently
ETA: 10-27-2026 7pm (will be updated as I get into it)

@meghan-oconnell offered to review in my place, so I've unassigned myself as reviewer.

[meghan-oconnell]

ETA: Friday 10/23 EOD
Availability: evenings and Thursday, Friday, Saturday morning

[meghan-oconnell]

Hey! I am still working on this PR. Learning a bit more about how Github Actions work so I can test this right. I will be done with it by EOD 10/24.

[meghan-oconnell]

Great work @castillios ! I tested this and mostly saw successes (except for the empty PR issue I noted), the comments made when appropriate, and the artifacts made.

I included two notes on other fixes we may want to consider here. However, those issues already existed. So I will approve your code.

When it comes to those or fixes, I can create an ER if we think those are somethings we'd want to update. Let me know your opinion there, thanks!

[meghan-oconnell]

Hey @castillios ! Thank you for your patience as I reviewed this. Your code is looking great. I tested it and mostly saw successes, the artifact made, and the comment made on the PR when appropriate.

There was one thing. It looks like this was already an issue in the code before, but in testing this, I noticed that when you submit with a blank PR message, it fails altogether.

I will link the fails so you can see the error message and include the error message I am seeing:

• https://github.com/meghan-oconnell/website/actions/runs/40116788210
  ... Error message: "post-pr-comment
  Unhandled error: TypeError: Cannot destructure property 'id' of 'artifact' as it is undefined."
• https://github.com/meghan-oconnell/website/actions/runs/40116770547
  ... Error messages: Check-For-Linked-Issue
  Unhandled error: TypeError: Cannot read properties of null (reading 'match')

To fix this, something like this might work:
const match = (pr.body ?? '').match(regex);
(though I haven't tested it)

Maybe we assume people will put something in that PR, especially since there is a template that auto populates, so it would't really come up. Let me know what you think there.

[daras-cu]

@meghan-oconnell this is a good point, it's probably rare someone would submit a blank PR but the code should handle it if it does happen.

[meghan-oconnell]

Hey @castillios! This work looks really good. I did have one question about the event actions we'd want to consider here and on line 2-4:

on:
  pull_request:
    types: [opened, edited]

Do we want to include "reopened" as well?

Here are the docs I was looking at where I got this idea: https://docs.github.com/en/rest/using-the-rest-api/github-event-types?apiVersion=2026-03-10#event-payload-object-for-issuesevent

[daras-cu]

@meghan-oconnell I do think it would be a good idea to include reopened too.

[daras-cu]

@meghan-oconnell I commented on your notes, I do agree with both points. I'll let @castillios weigh in too before we create any ERs, she is away until next week so we'll put a pin in it until she's back. Thanks for reviewing so thoroughly!