rhysd
Actionlint should check permissions passed to reusable workflows (in the same repository)
When calling reusable workflows, each reusable workflow requests permissions based on the permissions required for each job. The permissions must be granted by the calling workflow for the workflow to be valid.
If the calling workflow does not grant adequate permissions then GitHub Actions will fail the workflow run with an error like the following.
The workflow is not valid. .github/workflows/pull_request.tests.yml (Line: 64, Col: 3): Error calling workflow 'ianlewis/repo-template/.github/workflows/workflow_call.zizmor.yml@1ae42c4d4c64e09f3b01302bd64a20af0d82c4bd'. The workflow is requesting 'security-events: write', but is only allowed 'security-events: none'.
Actionlint should check for the correct permissions when the reusable workflow is being called from the same repository via uses: ./path/to/workflow.yml. Actionlint already checks for the existence of this file.
I think that is a good idea for reusable workflows open to the internet, but this is functionally a runtime error. Linting is more or less for static code analysis. I think we would get into a mess where someone is reusing a workflow that is private, requiring the provided GitHub token to have read access for all externally defined workflows and actions.
@holtkampjs I'm not really expecting actionlint to go off and check the permissions required for workflows located in other repositories. As you stated, the required permissions could change over time, leading to TOCTOU issues, or the reusable workflow could be private.
The issue is explicitly for workflows found in the same repository and referenced with a uses: ./path/to/workflow.yml. In that case, both the requested permission and required permissions are known and static since it's always the same revision. In that case, I think it would be useful to call that out beforehand.
Personally, I don't see much value in that as a feature. If the code is in your repo, you can just go look at it to determine which permissions you need.
Could you not say that about every actionlint feature? You could just look at your workflow to make sure it has the correct syntax no? The reason to use actionlint is to catch mistakes. I asked for this feature out of experience writing workflows and wasting time fixing them due to runtime errors that could be caught by static analysis.
I just stumbled upon this issue today. It is indeed a cool feature if you use reusable workflows but probably not enough interest in users as the issue was reported a month ago and the project is almost 5 years old. @holtkampjs would you accept a contribution for this feature?
@jcchavezs I don't really have any ground to make decisions on this project. The way I look at it, working code wins arguments.
I just experienced this problem myself after tightening the permissions directive in some reusable workflows. It would be great for Actionlint to flag when there's a mismatch between the permissions requested by a reusable workflow versus the permissions granted to it by a calling workflow in the same repo.
Agree on this we just hit the problem and given re-usable workflows in same repository are "auditable" for the required permissions it would be a very nice to have to know in advance if proper permissions are forwarded
Ran into this exact issue recently. We had a scheduled pipeline fail because the caller workflow didn't have the write permissions needed by the reusable one, but actionlint gave it a pass.
It would be super helpful if the tool could catch this locally, especially since it's already reading the reusable workflow file to check inputs
