Improve pull request previews

[dgarcia360]

Amplify triggers on every build, not only if there are pull request related changes.

We are evaluating to push directly to Amplify / S3 Bucket / PushPreview the artifact generated with the "Docs / PR" workflow.

[benipeled]

We should raise the priority for this item - the emails about amplify comments that are later deleted is annoying,
The plan is to use two workflow

1. Create (workflow already exists) - trigger for pull request events: opened, synchronize, reopened
   1.1 Build
   1.2 Test
   1.3 Publish to a dedicated folder on an S3 bucket, ex. s3://<URL>/<PR_NUMBER>
   1.4 Post a comment with a URL to the built docs

2. Delete - trigger for pull request events: closed
   2.1 Delete doc PR folder from the S3 bucket

If no one else started implementing something - I'll do

PS> We can avoid the second workflow by setting S3 lifecycle to auto-delete content > 90days (and mentioned it on the PR comment) it will save us a few $ on github-actions bill

[tzach]

The plan make sense to me, I will be happy to see a working demo.

PS> We can avoid the second workflow by setting S3 lifecycle to auto-delete content > 90days (and mentioned it on the PR comment) it will save us a few $ on github-actions bill

Less worries about the cost, and more about old, out dated preview floating around, maybe indexed by Google.

[benipeled]

The plan make sense to me, I will be happy to see a working demo.

PS> We can avoid the second workflow by setting S3 lifecycle to auto-delete content > 90days (and mentioned it on the PR comment) it will save us a few $ on github-actions bill

Less worries about the cost, and more about old, out dated preview floating around, maybe indexed by Google.

No worry about google (and other search engines) - should be blocked by robots.txt

[tzach]

@dgarcia360 I understand @benipeled already has a close-to-ready solution, so I need to work on this for now.
I would appreciate your help reviewing the propose solution (PR)

[dgarcia360]

Hi @benipeled,

The solution outlined will only work for users who are invited to the repo and have write permissions. Note that contributors submitting pull requests from forks will not be able to access the encrypted variable that will contain the S3 key.

Given this, I recommend triggering the docs build only when a label is added to a pull request by a maintainer or someone with direct write access, rather than on every push.

I have availability too if you need anything from my side.

[benipeled]

Thanks @dgarcia360 for the input I'll check this option

[benipeled]

The docs-preview implemented by a new Jenkins pipeline (part of the pkg repo)
@dgarcia360 I have no permissions to close this issue - please close it

[benipeled]

The docs-preview implemented by a new Jenkins pipeline (part of the pkg repo) @dgarcia360 I have no permissions to close this issue - please close it

@annastuchlik / @tzach please close this issue