ci: Refactor screenshot workflow #7773
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
joeyparrish
requested review from
littlespex,
avelad,
JulianDomingo,
theodab and
tykus160
|
Incremental code coverage: No instrumented code was changed. |
tykus160
approved these changes
Dec 18, 2024
theodab
approved these changes
Dec 18, 2024
This workflow, triggerable only by maintainers, had some potential security issues. This is a big refactor, and makes several changes: - Clean up description text (non-critical) - Add granular permissions to set status (without this, the workflow was broken since we changed default permissions) - Split the update-pr job into commit-new-screenshots (unprivileged) and update-pr (privileged as @shaka-bot) The commit-new-screenshots job runs code that the PR author controls, such as "npm ci" (controlled through package.json and package-lock.json), and "./build/updateScreenshots.py" (easily edited to do whatever). These steps could be used to do literally anything, including modify tools in /usr/bin on the workflow VM that are needed by the privileged steps. By moving the privileged steps into a completely separate job, we can ensure a clean slate without worrying about the VM's state. We only transfer the .git/ folder between the two jobs. So the commit-new-screenshots job will create the commit, and the update-pr job will actually push that commit from a clean VM.
joeyparrish
force-pushed
the
refactor-screenshot-workflow
branch
from
92a72ac to
1c10c03
Compare
This was referenced Dec 20, 2024
joeyparrish
added a commit
that referenced
this pull request
Jan 6, 2025
This workflow, triggerable only by maintainers, had some potential security issues. This is a big refactor, and makes several changes: - Clean up description text (non-critical) - Add granular permissions to set status (without this, the workflow was broken since we changed default permissions) - Split the update-pr job into commit-new-screenshots (unprivileged) and update-pr (privileged as @shaka-bot) The commit-new-screenshots job runs code that the PR author controls, such as "npm ci" (controlled through package.json and package-lock.json), and "./build/updateScreenshots.py" (easily edited to do whatever). These steps could be used to do literally anything, including modify tools in /usr/bin on the workflow VM that are needed by the privileged steps. By moving the privileged steps into a completely separate job, we can ensure a clean slate without worrying about the VM's state. We only transfer the .git/ folder between the two jobs. So the commit-new-screenshots job will create the commit, and the update-pr job will actually push that commit from a clean VM. The job is once again functional, and for the first time, actually safe.
joeyparrish
added a commit
that referenced
this pull request
Jan 6, 2025
This workflow, triggerable only by maintainers, had some potential security issues. This is a big refactor, and makes several changes: - Clean up description text (non-critical) - Add granular permissions to set status (without this, the workflow was broken since we changed default permissions) - Split the update-pr job into commit-new-screenshots (unprivileged) and update-pr (privileged as @shaka-bot) The commit-new-screenshots job runs code that the PR author controls, such as "npm ci" (controlled through package.json and package-lock.json), and "./build/updateScreenshots.py" (easily edited to do whatever). These steps could be used to do literally anything, including modify tools in /usr/bin on the workflow VM that are needed by the privileged steps. By moving the privileged steps into a completely separate job, we can ensure a clean slate without worrying about the VM's state. We only transfer the .git/ folder between the two jobs. So the commit-new-screenshots job will create the commit, and the update-pr job will actually push that commit from a clean VM. The job is once again functional, and for the first time, actually safe.
joeyparrish
added a commit
that referenced
this pull request
Jan 6, 2025
This workflow, triggerable only by maintainers, had some potential security issues. This is a big refactor, and makes several changes: - Clean up description text (non-critical) - Add granular permissions to set status (without this, the workflow was broken since we changed default permissions) - Split the update-pr job into commit-new-screenshots (unprivileged) and update-pr (privileged as @shaka-bot) The commit-new-screenshots job runs code that the PR author controls, such as "npm ci" (controlled through package.json and package-lock.json), and "./build/updateScreenshots.py" (easily edited to do whatever). These steps could be used to do literally anything, including modify tools in /usr/bin on the workflow VM that are needed by the privileged steps. By moving the privileged steps into a completely separate job, we can ensure a clean slate without worrying about the VM's state. We only transfer the .git/ folder between the two jobs. So the commit-new-screenshots job will create the commit, and the update-pr job will actually push that commit from a clean VM. The job is once again functional, and for the first time, actually safe.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This workflow, triggerable only by maintainers, had some potential security issues. This is a big refactor, and makes several changes:
The commit-new-screenshots job runs code that the PR author controls, such as "npm ci" (controlled through package.json and package-lock.json), and "./build/updateScreenshots.py" (easily edited to do whatever). These steps could be used to do literally anything, including modify tools in /usr/bin on the workflow VM that are needed by the privileged steps.
By moving the privileged steps into a completely separate job, we can ensure a clean slate without worrying about the VM's state. We only transfer the .git/ folder between the two jobs. So the commit-new-screenshots job will create the commit, and the update-pr job will actually push that commit from a clean VM.
The job is once again functional, and for the first time, actually safe.