PRs: Add preview workflow#905
Conversation
Adds a PR preview workflows that - Create a build from PR itself without secrets - Publishes build artifact to surge.sh - Tears down surge preview on PR closure Reason for a split between build and publish has to do with a workaround for security where workflows that are triggered on a pull request cannot access secrets. As the deploy workflow just publishes an artifact it can have access to secrets. Note this only has to do with PRs from forks and does not matter for PRs within the repo itself. We still need to explicitly approve workflows to run on outside contributors. Signed-off-by: Freya Gustavsson <freya@venefilyn.se>
| jobs: | ||
| # Important - the job id: | ||
| # MUST be unique across all surge preview deployments for a repository as the job id is used in the deployment URL | ||
| # MUST be kept in sync with the job id of the teardown stage (this id is used by the surge-preview action to forge the deployment URL) |
There was a problem hiding this comment.
Just from reading the yaml here I can not figure out how these requirements are implemented. I think it would be good to explain that here as well. Is the job id maybe just the string "deploy" on the next line?
(I am super naive with yaml and github workflows, and if I had to change this file for some reason I wouldn't understand what I have to do concretely to not violate the requirements. If I can't change the "deploy" name on the next line, it would really help me to have that spelled out explicitly.)
There was a problem hiding this comment.
I made changes since this was added I wonder if I can remove it.. I'll double-check
| pull-requests: write # Needed to comment on PRs | ||
|
|
||
| jobs: | ||
| deploy: # Must match the job ID from the deploy workflow |
There was a problem hiding this comment.
Right, got it. "deploy" is the job id. Maybe I am just too ignorant...
|
I have been hosting pre-views of my PRs on Github itself, as explained in the README in this repo. But this works only for a single PR at a time and is not very automatic. So this is better, thanks! |
|
I would like @allisonkarlitskaya to approve this and install the token. |
It also doesn't work for me. Likely, both this repo and the forks of you and others got the deprecated deployment version enabled and I just can't. There isn't a way for me to deploy from a fork apart from like building locally and pushing to a gh-pages branch |
2 participants
Adds a PR preview workflows that
Reason for a split between build and publish has to do with a workaround
for security where workflows that are triggered on a pull request cannot
access secrets. As the deploy workflow just publishes an artifact it can
have access to secrets. Note this only has to do with PRs from forks and
does not matter for PRs within the repo itself.
We still need to explicitly approve workflows to run on outside
contributors.
Before merging this a surge token needs to be added to secrets as
SURGE_TOKEN.Ask me for token to add and I'll send it as I can't access the env or secrets in this repo
Signed-off-by: Freya Gustavsson freya@venefilyn.se