-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error when using workflow: ”The nested job 'genmatrix' is requesting 'pull-requests: read'“ #137
Comments
Looks like the relatively recent security hardening has resulted in the default GitHub token that your repository uses for GitHub Actions not having enough permission to run the workflow. I don't think this was an intended side effect. You'll need to make the following changes for the CI to run: name: CI
on:
push:
pull_request:
workflow_dispatch:
+
+ permissions: {}
jobs:
ci:
name: CI
uses: silverstripe/gha-ci/.github/workflows/ci.yml@v1
+ permissions:
+ pull-requests: read
+ contents: write The To ensure you protect yourself from malicious actors, I recommend you set the "Fork pull request workflows from outside collaborators" setting in
I'll work on getting the README here updated, but for now hopefully that gives you a way forward. |
Thanks, @GuySartorelli, these changes work fine to fix the issue. |
Sweet. FYI we're working on an improvement that will allow you to just have |
^ I think you won't even need to specify
|
@GuySartorelli A bunch of the unmerged PRs created by module standardiser are targetting the next-minor, they should be targeting the next-patch branch? The top load of PRs that were merged targetted next-patch |
@emteknetnz oh! Thank you for noticing that, yeah they should all be for next-patch. I'll sort that out. |
@GuySartorelli noticed your new PR commit messages have:
Those shouldn't be there |
It's a comment in a commit message, it really affects nothing. But I'll remove it to avoid ping pong. |
@martinheise You should be able to demote |
All PRs merged and follow-up actions performed. |
See silverstripe/gha-ci#137 - work was done to reduce the scope of permissions required to run CI.
Module version(s) affected
^1.9
Description
I have used the workflow as described with default setup pointing to tag “v1”, both in a new repository and in an older one (both containing Silverstripe modules):
For both I get an error message now when running the CI workflow related to permission (details see below).
As the older repository used to work this way without code changes in the meantime, I tried several configurations using different tags – it seems the issue appears with branch 1.9, while 1.8. still runs fine.
How to reproduce
Setup a basic CI workflow as described on https://github.com/silverstripe/gha-ci/ in some repository:
and trigger the CI action manually or by pushing a branch.
The action aborts with error message:
Changing the referenced tag/branch for the included job to e.g.:
Using branch 1.8 here still works and the job runs successfully, new branches 1.9, 1.10, 1.11, 1.12 fail with the same message.
Possible Solution
I’m not sure if this about wrong permission inside gha-ci module, or if some different setup in the repository using it is required because of some change – in the latter case just the documentation would need enhancement.
Additional Context
Thanks for checking!
Validations
silverstripe/installer
(with any code examples you've provided)Notes
contents:read
instead ofcontents:write
in the ci.yml workflow.PRs
After merging, reassign to Guy so they can do these steps
gha-tag-release
to2
2.0.0
ofgha-tag-release
v2
ofgha-tag-release
Next set of PRs
Important
DO NOT merge these until the PRs above are merged, and the steps above are complete.
After this set of PRs is merged, reassign to Guy to:
The text was updated successfully, but these errors were encountered: