Skip to content
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

Closed
9 tasks done
martinheise opened this issue Jul 26, 2024 · 10 comments
Closed
9 tasks done
Assignees

Comments

@martinheise
Copy link

martinheise commented Jul 26, 2024

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:

name: CI

on:
  push:
  pull_request:
  workflow_dispatch:

jobs:
  ci:
    name: CI
    uses: silverstripe/gha-ci/.github/workflows/ci.yml@v1

and trigger the CI action manually or by pushing a branch.

The action aborts with error message:

The workflow is not valid. .github/workflows/ci.yml (Line: 9, Col: 3): Error calling workflow 'silverstripe/gha-ci/.github/workflows/ci.yml@v1'. The nested job 'genmatrix' is requesting 'pull-requests: read', but is only allowed 'pull-requests: none'. .github/workflows/ci.yml (Line: 9, Col: 3): Error calling workflow 'silverstripe/gha-ci/.github/workflows/ci.yml@v1'. The nested job 'patchrelease' is requesting 'contents: write', but is only allowed 'contents: read'.

Changing the referenced tag/branch for the included job to e.g.:

silverstripe/gha-ci/.github/workflows/[email protected]

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

  • Check that there isn't already an issue that reports the same bug
  • Double check that your reproduction steps work in a fresh installation of silverstripe/installer (with any code examples you've provided)

Notes

PRs

After merging, reassign to Guy so they can do these steps

  • Set default branch for gha-tag-release to 2
  • Manually tag 2.0.0 of gha-tag-release
  • Manually tag v2 of gha-tag-release
  • Run module standardiser against the next-patch branch

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:

  • Tag new minor releases for the various affected gha repos
  • Redeploy elvis so it picks up on the changes
  • Archive gha-gauge-release
@GuySartorelli
Copy link
Member

GuySartorelli commented Jul 28, 2024

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 contents: write is a bit unfortunate - that is required by silverstripe/gha-tag-release which will be skipped in your repos, so that permission won't ever actually be used. Nevertheless GitHub requires that it's provided.

To ensure you protect yourself from malicious actors, I recommend you set the "Fork pull request workflows from outside collaborators" setting in https://github.com/<org>/<repo>/settings/actions to one of

  • Require approval for first-time contributors
  • Require approval for all outside collaborators

I'll work on getting the README here updated, but for now hopefully that gives you a way forward.

@martinheise
Copy link
Author

Thanks, @GuySartorelli, these changes work fine to fix the issue.

@GuySartorelli
Copy link
Member

GuySartorelli commented Jul 29, 2024

Sweet. FYI we're working on an improvement that will allow you to just have contents: read instead of giving it write permissions.

@emteknetnz
Copy link
Member

emteknetnz commented Jul 29, 2024

^ I think you won't even need to specify contents: read after the improvements? The default github token in repos provides read level access.

[x] Read repository contents and packages permissions
Workflows have read permissions in the repository for the contents and packages scopes only.

@emteknetnz
Copy link
Member

@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

@GuySartorelli
Copy link
Member

@emteknetnz oh! Thank you for noticing that, yeah they should all be for next-patch. I'll sort that out.

@emteknetnz
Copy link
Member

@GuySartorelli noticed your new PR commit messages have:

Co-authored-by: DDEV User <[email protected]>

Those shouldn't be there

@GuySartorelli
Copy link
Member

GuySartorelli commented Aug 1, 2024

It's a comment in a commit message, it really affects nothing. But I'll remove it to avoid ping pong.
Edit: I guess it would have technically resulted in tagging patches that didn't need tagging, for what that's worth.

@GuySartorelli
Copy link
Member

@martinheise You should be able to demote contents:write to contents:read now.

@GuySartorelli
Copy link
Member

All PRs merged and follow-up actions performed.

GuySartorelli added a commit to GuySartorelli/silverstripe-composable-validators that referenced this issue Aug 5, 2024
See silverstripe/gha-ci#137 - work was done to
reduce the scope of permissions required to run CI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants