-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Add PR preview deployments #5131
Conversation
# `preview_deploy` has access to the repositories secrets (so it can push to the pr preview repo) but won't run | ||
# any untrusted code (it will just extract the build artifact and push it to the pages branch where it will | ||
# automatically be deployed). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
…but I guess it doesn't prevent a malicious user from simply changing the .yml
in the PR.
But there should be some way to configure it so that it is always the .yml
from master
that is run? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The pull_request trigger will run workflows from the pr branch, so yes, they could modify the yml. But the workflow won't get any access to secrets and will only get a read only GITHUB_TOKEN, so it wouldn't be a problem.
Worst thing they could do is change the output to meta.json to point at a different branch and overwrite someone elses preview deployment that way 🤔
It's possible to run the workflow from master via pull_request_target but then it would be unsafe to build the untrusted code since workflows using that have access to secrets.
target-folder: ${{ env.URL_SLUG }} | ||
ssh-key: ${{ secrets.DEPLOY_KEY }} | ||
commit-message: "Remove preview for PR ${{ env.URL_SLUG }}" | ||
single-commit: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: hot tip is to configure your editor to
A) ensure a final newline on save
B) trim trailing whitespace on save
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can add a https://editorconfig.org/ to egui so everyone has the same config
This adds preview deployments that will deploy a version of egui_demo_app for each pull request, making things easier to review / test.
Some notes on security:
The preview deployment is split in two workflows, preview_build and preview_deploy.
preview_build
runs on pull_request, so it won't have any access to the repositories secrets, so it is safe tobuild / execute untrusted code.
preview_deploy
has access to the repositories secrets (so it can push to the pr preview repo) but won't runany untrusted code (it will just extract the build artifact and push it to the pages branch where it will
automatically be deployed).
To set this up, a DEPLOY_KEY secret needs to be added, which allows the action to push the compiled artifacts into this repository: https://github.com/egui-pr-preview/pr
The deploy key is the private key part of a key generated via ssh-keygen. The public key is set as a deploy key in that repo.
I have created the repo on a separate github org, so it won't be directly associated with emil or egui in case someone pushes something naughty.
I have set this up in my fork of egui to show how this works:
(It's unfortunately only available a couple seconds after the bot writes the comment, because the pages deployment action is run independently on the other repository)
I'll leave the PR in draft until the DEPLOY_KEY is set up