feat: deploy dev pages preview for fork pull requests#122
Conversation
amanabiy
force-pushed
the
feat/allow-test-pages-for-prs
branch
2 times, most recently
from
f0556ec to
4a09a15
Compare
| if: github.event_name == 'pull_request' | ||
| if: > | ||
| github.event_name == 'pull_request' && | ||
| github.event.pull_request.head.repo.full_name == github.repository |
There was a problem hiding this comment.
Internal PRs only. Fork PRs can't deploy here (no secrets), and they are handled separately by deploy-fork-preview.yml. Keeping this guard here means consumers don't need to add it to their own deploy caller job.
| runs-on: ubuntu-latest | ||
| continue-on-error: true | ||
| environment: | ||
| name: fork-${{ inputs.artifact-name }} |
There was a problem hiding this comment.
Using a separate environment is helpful for example, if we later want to require an extra layer of approval before forked-PR previews are deployed, we can enable it on this environment.
| with: | ||
| name: ${{ inputs.artifact-name }} | ||
| path: build | ||
| run-id: ${{ github.event.workflow_run.id }} |
There was a problem hiding this comment.
the artifact lives in the build run (a different run), so we fetch it by run-id via the REST API (hence github-token + actions: read). The run id comes from the caller's workflow_run payload.
| id: deploy | ||
| uses: cloudscape-design/actions/.github/actions/deploy-static@main | ||
| with: | ||
| role-to-assume: ${{ secrets.AWS_PREVIEW_ROLE_ARN }} |
There was a problem hiding this comment.
How do the secrets work on workflows running for forks? Is there a risk that a fork can modify the workflow on their end to log out the secrets? Or are we relying on manual approval of the deploys to enforce that?
There was a problem hiding this comment.
It mainly relies on human review to make sure we don't deploy anything unexpected. On top of that, we can add an approval step on each repository's environment so every deployment is intentional.
Is it gated technically/automatically? Yes, unless I missed something, what I did is split the flow: the artifact is built in the pull_request run, where no secrets are available, and a separate workflow only uploads that pre-built artifact so the run that has the secrets never builds or runs the fork's code.
| name: Deploy fork preview | ||
|
|
||
| on: | ||
| workflow_call: |
There was a problem hiding this comment.
A new workflow_run triggered deploy
This uses workflow_call — should there be some other workflow that calls this? Or should this be workflow_run?
There was a problem hiding this comment.
Yes, this is called from the workflow_run of other repositories. For example, in chat-components I will add a workflow that will fire after the build end, and it will be using this deply fork preview workflow_call.
Pass --no-follow-symlinks to so the deploy step never dereferences symlinks in the source directory. The deploy runs with the AWS preview credentials, and for fork PR previews. Without this flag, follows symlinks by default, so a symlink planted in the artifact could cause the runner's temporary AWS credentials to be copied into the public, CloudFront-fronted preview bucket.
amanabiy
force-pushed
the
feat/allow-test-pages-for-prs
branch
from
ed4e072 to
5c2237f
Compare
3 participants
Description of changes:
Forked-PR workflows run without secrets, so they can't deploy previews. Add a workflow_run-based privileged deploy that runs after the build, behind the existing environment approval gate, so a maintainer can approve and publish a fork's dev-pages preview.
Merging this PR won't make it automatically deploy the dev pages. It needs to be added to each repository for example for chat-components example draft PR
Approach:
workflow_runtriggered deploy runs after the build, from the default branch, with secrets, and never checks out or runs fork code. It only downloads the prebuilt artifact and uploads it via the existing deploy-static action.How consuming repos use it
Each repo does two small things: let its build run for forks (so the artifact is produced), and add a tiny workflow_run wrapper that calls this reusable workflow. The wrapper is the only new per-repo file (workflow_run must live in the same repo).
for example for chat-components example draft PR
Issue #, if available: AWSUI-53554
I tested it here on a personal repository. Here is an example of a deploy that requires approval.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.