Amplify-console: Previews for public projects

Created on 14 Jul 2020 · 15Comments · Source: aws-amplify/amplify-console

Is your feature request related to a problem? Please describe.

I would like to use Amplify for public projects on GitHub, and have PR previews to build the project during code review.

I expect it is intentional that this is not supported currently because _anyone_ could open a pull request on a public project and currently that would automatically kick off an Amplify build, and there are costs and service availability issues involved.

Describe the solution you'd like

I propose that instead of starting an Amplify job automatically when a pull request is opened or updated, support a configuration where the job is triggered by a comment on the pull request that contains a build phrase (e.g. @amplify build), and only if the comment author has write privileges to the repo (or alternatively, configure a list of github usernames allowed to trigger builds).

Personally, I'd like to see this anyway, even for private repos, to have finer control over PRs that start an Amplify build. I mean, if I'm just updating a .gitignore file, really no reason to start a build... :D

feature request

Source

lorengordon

👍3

All 15 comments

@lorengordon This is what our team do currently. Before our repo goes public, we set up preview settings to reuse the backend-environment. Since our repo is public and can't use preview anymore, when a developer submits a new PR in the GitHub, he/she needs to deploy an application using his/her PR branch in the Amplify console using below commands

aws amplify create-branch --app-id=AmplifyAppId --branch-name=GitHubBranchName --backend-environment-arn=BackendEnvARN

aws amplify start-job --app-id=AmplifyAppId --branch-name=GitHubBranchName --job-type=RELEASE

Thus, it is just like trigger the Amplify preview manually. Reviewer also needs to disconnect the branch after that PR is merged.

aws amplify delete-branch --app-id=AmplifyAppId --branch-name=GitHubBranchName

Hope it helps!

ps. I am also looking forward to seeing preview will support public repo in the future.

yinlinchen on 31 Jul 2020

👍1

+1 to this. Or just implement a filter list, only build if the contributor is in the list of "approved" people.

sean-smith on 5 Aug 2020

@sean-smith I really think a comment-based webhook event (or a tag, I suppose) will be a better implementation overall, because with a public project the contributor may be anyone, and we'd likely want to run builds on PRs submitted by contributors that might not be on the "approved" list.

In the comment approach, an "approved" user comments with the build command, e.g. @amplify build.

In the tag approach, a member with tag-permissions (or a github action) would apply a keyword tag, e.g. needs-amplify-build

lorengordon on 6 Aug 2020

👍1

@sean-smith @lorengordon @abhi7cr I create a amplify-preview-actions for this. Basically, you can define your own rule (e.g. combine GitHub review_requested, tags and pull_request) to trigger this GitHub action to deploy a version in your Amplify app console with either a existing backend env or other backend env under the same AmplifyAppId. You can see examples here. Thus, a open source GitHub public project can have a preview with this GitHub action.

yinlinchen on 13 Sep 2020

❤1

@yinlinchen Is there a link to the generated preview available to the reviewer?

sean-smith on 14 Sep 2020

@sean-smith Yes. It does now. https://github.com/yinlinchen/amplify-preview-actions/pull/4

yinlinchen on 14 Sep 2020

I've gone ahead and implemented @yinlinchen amplify-preview-actions action on my github repo. My only complaint is it seems to only work when the PR is created by diffing 2 branches on the same repo. Not fork!

This is because github secrets are only accessible on actions triggered by a PR from a local diff and not a remote fork. There's probably good reasons for this but it's still annoying because it goes against the typical github Fork > Push > PR workflow and limits PR previews to collaborators.

sean-smith on 17 Sep 2020

@sean-smith ~~Yes, GitHub won't let you access the secret from Fork.~~ Update There is nothing we can do and currently, this is the best we can do. I use this in our team projects to enable public repos having Amplify PR preview, at least for my team. It is definitely better than we just lose the PR preview once we make our project public!

yinlinchen on 17 Sep 2020

~~BTW, I found multiple posts about that too, just paste two here.~~

-~~Allow secrets to be shared with forks from trusted Actions.~~
-~~Make secrets available to builds of forks~~
Outdated

yinlinchen on 17 Sep 2020

@sean-smith I just did some diggings and I found this PR previews only work for branches on origin, not for forks.. So github Fork > Push > PR does not support by Amplify console, even in a private Github repo.

See GitHub Actions improvements for fork and pull request workflows. I did verify that it is working when I changed pull_request to pull_request_target. Apply to amplify-preview-actions, the actions will deploy and close PR preview branch in the Amplify console with a PR for Forks, however, amplify console can't find the fork branch and clone the source code, and thus, can't build it. The PR merged and closed scenario is working well with this update.

This Fork workflow for Amplify PR preview is now on AWS Amplify's hand now.

I've gone ahead and implemented @yinlinchen amplify-preview-actions action on my github repo. My only complaint is it seems to only work when the PR is created by diffing 2 branches on the same repo. Not fork!

yinlinchen on 20 Sep 2020

amplify console can't find the fork branch and clone the source code, and thus, can't build it

The pull request does have the ref for the code. Do amplify previews not use the pull/<num>/head ref to checkout the pull request? This works when the pr is from a fork and when it is from the same repo.

git fetch origin pull/<pull#>/head:pr<pull#>
git checkout pr<pull#>

https://github.community/t/checkout-a-branch-from-a-fork/276/2

lorengordon on 20 Sep 2020

@yinlinchen we just added support for fork PRs as mentioned here. We will also support forks of private repos which have Amplify backends. We will continue to be unable to support public repos with Amplify backends.