Added the split method for labeler workflow#788
Conversation
| github-token: ${{ secrets.GITHUB_TOKEN }} | ||
| script: | | ||
| const labels = [ | ||
| { name: 'cli', color: '0E8A16', description: 'Changes to CLI components' }, |
There was a problem hiding this comment.
Instead of trying to encode the different label categories into the workflow job itself, maybe instead we could use the PR number parameter to actions/labeler in the label-apply workflow like this:
- uses: actions/labeler@v6
with:
pr-number: |
1
<PR number we got from the artifact download>
We should double check that the labeler doesn't try to read the untrusted code. But my understanding is that the action does not checkout the PR code, just analyzes based on the files that have been changed.
Note: I think it would be unsafe to read the labeler's configuration file from the PR, we might have to settle for using the configuration in main. But we should look into that as well.
There was a problem hiding this comment.
Thanks for the suggestion, Katie! I've updated the workflows to use actions/labeler@v5 with the PR number from the artifact as you recommended.
| permissions: | ||
| issues: write |
There was a problem hiding this comment.
See #781, the top level permissions should always be the least permissive possible and any additional permissions should be set at the job level.
There was a problem hiding this comment.
I changed the permissiion to read only
…atie's security recommendations
|
@katiewasnothere can you look at the changes I made please let me know if they are good |
| @@ -0,0 +1,65 @@ | |||
| name: Color Labels | |||
There was a problem hiding this comment.
I don't think we need this. We can make them by hand for now.
There was a problem hiding this comment.
should i remvoe the colors file
| with: | ||
| pr-number: ${{ steps.pr-number.outputs.number }} | ||
| repo-token: ${{ secrets.GITHUB_TOKEN }} | ||
| configuration-path: .github/labeler.yml |
There was a problem hiding this comment.
Do we need to have checked out the repo to access this file?
There was a problem hiding this comment.
Yes, we need to checkout the repository to access the .github/labeler.yml configuration file. Without checkout, the workflow runner won't have access to any files from the repo, including the labeler configuration.
There was a problem hiding this comment.
I don't see the repo being checked out in this workflow
There was a problem hiding this comment.
I think I accidentally removed it let me add it again. Thank you Katie for pointing that out.
|
@katiewasnothere could you please review this update code |
|
Hi @Ronitsabhaya75, I asked @jglogan to take a look at the PR as well for another set of eyes on the security of this change. I think he had some concerns about if we wanted to take this change, but I'll let him add his thoughts here. |
thank you so much for letting me know |
- This can basically Help teams know what changes are made in pr - Added the split approach @katiewasnothere suggested using openssf - Added additional feature for colors - Currently this is for CLI only later we can add multiple - Labeling flow - TRIGGER: Pull Request Opened (untrusted code) - READ-ONLY stage: just save job number to artifact - WRITE: load job number artifact, use GH labeler action with `labeler.yml` from repo
- This can basically Help teams know what changes are made in pr - Added the split approach @katiewasnothere suggested using openssf - Added additional feature for colors - Currently this is for CLI only later we can add multiple - Labeling flow - TRIGGER: Pull Request Opened (untrusted code) - READ-ONLY stage: just save job number to artifact - WRITE: load job number artifact, use GH labeler action with `labeler.yml` from repo
Type of Change
Motivation and Context
This can basically Help teams know what changes are made in pr
Testing
Structure how workflow runs