actions
Upgrade ESM and node-fetch
- Added package.json in dist/setup to specify module type as ESM.
- Updated jest.config.js to support ESM with ts-jest and added moduleNameMapper for .js extensions.
- Created jest.setup.js to ensure Jest globals are available in ESM mode.
- Modified test script in package.json to use node with experimental VM modules for Jest.
- Updated imports in various distribution files to include .js extensions for ESM compatibility.
- Adjusted tsconfig.json to exclude tests directory and maintain ESM settings.
- Updated package-lock.json to include new dependencies and their versions.
Description: Describe your changes.
Related issue: Add link to the related issue.
Check list:
- [ ] Mark if documentation changes are required.
- [ ] Mark if tests were added or updated to cover the changes.
After some searching through GitHub I found out that this action relies on a special undocumented token that is made available to actions as environment variable and is unrelated to GITHUB_TOKEN. Side note: this token is not made available to run: scripts, only to actions.
I created a small demo that shows how with the code of the upload-artifact action someone can create a seemingly innocent action that overwrites previously uploaded artifacts. This is not great if publishing of artifacts to package repositories is fully automated.
One possible solution would be if artifacts could be marked as immutable so that they can't be overridden, and maybe that should be the default.
I am also interested in the documentation of what permissions are required. None of the GitHub Token permissions documented seem relevant.
After some searching through GitHub I found out that this action relies on a special undocumented token that is made available to actions as environment variable and is unrelated to GITHUB_TOKEN. Side note: this token is not made available to run: scripts, only to actions.
If that is true, then we also need advice about how to lock down that token.
I've stumbled across this issue as I'm currently exploring the implications for our workflow files of moving our org default access level from 'permissive' to 'restricted' (see Permissions for the GITHUB_TOKEN and workflow syntax: permissions).
The greater focus on finer grained permissions scope is a welcome improvement to the GitHub Actions ecosystem, however I think the developer experience would be greatly enhanced were GitHub to take the initiative to explicitly document permissions required (in the same terms as referred to in workflow files) in the actions published under this org.
At the time of writing this I'm yet to discover whether invoking this action with the default restricted permissions will fail my workflows or not. I could, perhaps, spend some time exploring the multiple layers of source code orchestrated to achieve what this action does - but, honestly, I don't have the time for that. So, as is so often the case, I'm going to resort to 'suck and see' - i.e. make the change and see if stuff breaks. Not ideal.
agreed there's a lack of support. Once you understand how permissions work, you can make an informed decision. But it takes a little getting used to :-)
In the meantime, try https://github.com/naveensrinivasan/ghactionspermissions, written by someone on my team https://github.com/ossf/scorecard. The tool allows you to extract permission failure from a check run and tells you which permissions you need. FYI @naveensrinivasan
agreed there's a lack of support. Once you understand how permissions work, you can make an informed decision. But it takes a little getting used to :-)
In the meantime, try https://github.com/naveensrinivasan/ghactionspermissions, written by someone on my team https://github.com/ossf/scorecard FYI @naveensrinivasan
Don't use that tool. Sorry, it is not the right approach. Here is the discussion https://github.com/github/codeql-action/pull/689#issuecomment-919402768
I ran some tests on a private repo using a workflow where the base permissions were set to permissions: {}.
It seems that the only permission needed for uploading an artifact with actions/upload-artifact in a private repo is contents: read.
