Specify default permissions for pull-request-trigger.yml and wr-pull-request-trigger.yml

Prerequisites

Be a member of Hack for LA. (There are no fees to join.) If you have not joined yet, please follow the steps on our Getting Started page and attend an onboarding session.
You have already read our How to Contribute to Hack for LA Guide.

Overview

We need to update the default permissions for the GitHub workflow specified in pull-request-trigger.yml and wr-pull-request-trigger.yml, so that it does not have more permissions than it needs.

Details

To align with GitHub security best practices, we want to specify the minimum required permissions for each workflow via a top-level permissions: block to ensure that workflows only have the access they need by default.

Every GitHub Actions workflow automatically receives a GITHUB_TOKEN with a set of default repository permissions defined in the repo settings which may result in the workflow having more permissions than it needs to complete its job. By explicitly defining minimum default permissions at the workflow level, we can ensure that workflow has only the permissions it needs. Then if a job or step requires more access, those permissions can be explicitly granted using job-level permissions statements or step-level tokens (PATs).

We performed an audit to identify the minimum top-level permissions required for each workflow. The goal of this and related issues is to verify that each workflow continues to function correctly with the explicitly defined permissions. This approach helps minimize unnecessary privileges and strengthen overall repository security.

For additional info, see issue #8178 and GitHub's recommendation for security best practice.

Action Items

Note that this issue involves testing GitHub Actions. See "Resources/Instructions" below for how to set up your personal environment for testing.
Refer to pull-request-trigger.yml.

Review the file to understand how the workflow is triggered. This is specified near the top of the YML in the on: section.
Near the top of the file immediately before the line jobs: insert:
```
  permissions:
    contents: read
    issues: write
```
Use clean formatting: make sure there is one line separation above and one below the permissions block.

Next, refer to wr-pull-request-trigger.yml.

Review the file to understand how the workflow is triggered. This is specified near the top of the YML in the on: section.
Near the top of the file immediately before the line jobs: insert:
```
  permissions:
    contents: read
```
Use clean formatting: make sure there is one line separation above and one below the permissions block.
If the workflow includes line(s) similar to the following, you will need to change these to match your situation before the workflow will run correctly:
```
if: github.repository == 'hackforla/website'
```
or
```
    branches:
    - 'gh-pages'
```
Trigger the workflow to confirm whether it runs successfully with no further changes to the permissions. Note that the second workflow is triggered by completion of the first.
If there are errors:
- Try to determine the nature of the error, and whether it is occurring due to a mismatched repo or branch name.
- If you cannot track down the error, consult with the team via Slack or the weekly meetings to report your findings and get additional direction.
If there are no errors, submit the PR like usual. Include a link to your test log.

Resources/Instructions

Refer to The "Hack for LA's GitHub Actions" Wiki guide needs additional explanation #6537 (comment), especially Tips 6, 7, and 8, if you have not already created you personal environment for testing.
How to Test GitHub Actions
Additional Notes for GitHub Actions
Tokens, Secrets, Scopes, & Permissions

Unfortunately haven't had the time to start this issue just yet
Only blocker is time
I'm available 9/12 9am-2pm, 9/14 after 6pm, 9/15 after 3pm
I may need a couple more days to complete this issue, new ETA should be 9/16 (Edit: New ETA is 9/22. I'd like to complete it before next Tuesday and as I need to take the time to understand the issue & get feedback on a proposed implementation)

@daras-cu

Hi @daras-cu, I had an idea to implement a fix which I'll work on in the coming days! In the meantime I'd like some feedback on my thought process to make sure I understand the issue and what it's asking:

Following Will's proposed implementation to troubleshoot the 403 error and his note below:

The more difficult part is that the functionality to post a comment needs to move from pull-request-trigger.yml to wr-pull-request-trigger.yml, and the first workflow probably needs to pass the second an artifact similar to set-pr-labels.yaml and wr-set-pr-labels.yaml.

I was thinking about splitting up the logic in check-linked-issue.js (the script used by pull-request-trigger.yml) between checking if issues are linked and the ability to post PR comments. Rather than making separate modules, this refactor could split them from one main() call into helper functions. Similar to how set-pr-labels.js has a split. This would also be useful for implementing artifacts.

Would this be a solid implentation to start with?

I myself don't have too much experience working with GHA artifacts so I'm linking a few below for my reference as I work on this issue. If there are any resources or ideas you'd like to add please share them!

@castillios

@castillios I think you're on the right track, we will need to split up the main function in check-linked-issue.js but I believe both functions can stay in the same file like in set-pr-labels.js, then each workflow can call the relevant function. It does seem like an artifact is the way to pass the desired comment from one workflow to another. I haven't worked with them either but I found one other resource in GitHub's documentation that matches what we'll be doing pretty closely: Using data from a triggering workflow.

Let me know how it goes once you start working, as always we may have to change tactics but in theory what you're thinking of should work!

Progress: I have the idea in mind, I just need to go ahead and implement then test.
Blockers: Time. I have unfortunately been busier than expected this past week.
Availability: 9/27 after 8PM, 9/28 after 7PM, 9/30 all day
ETA: By 9/29 I should have a PR up

@daras-cu

Hi @daras-cu. Apologies for the delay, I've created a PR for this issue: #8815

Navigation Menu

Repository navigation

Specify default permissions for `pull-request-trigger.yml` and `wr-pull-request-trigger.yml` #8590

Prerequisites

Overview

Details

Action Items

Resources/Instructions

17 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Specify default permissions for pull-request-trigger.yml and wr-pull-request-trigger.yml #8590

Description

Prerequisites

Overview

Details

Action Items

Resources/Instructions

Activity

17 remaining items

hfla-graphql-app commented on Sep 11, 2026

castillios commented on Sep 11, 2026

castillios commented on Sep 16, 2026

daras-cu commented on Sep 17, 2026

hfla-graphql-app commented on Sep 25, 2026

castillios commented on Sep 27, 2026

castillios commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Specify default permissions for `pull-request-trigger.yml` and `wr-pull-request-trigger.yml` #8590