Add: PR Preview

[RaulTrombin]

Sets up a cockpit preview available directly on PR,
works with main deployment branch and automatically clean previews once they are merged/closed.
Details: https://github.com/rossjrw/pr-preview-action

[RaulTrombin]

Looks like we cant't run safely from forks.
rossjrw/pr-preview-action#6

emilk/egui#5131

[rafaellehmkuhl]

Looks like we cant't run safely from forks. rossjrw/pr-preview-action#6

emilk/egui#5131

So it wouldn't work with PR made from forks? Or it just wouldn't work in the fork repositories? The first is a problem, the second is not.

[RaulTrombin]

Looks like we cant't run safely from forks. rossjrw/pr-preview-action#6
emilk/egui#5131

So it wouldn't work with PR made from forks? Or it just wouldn't work in the fork repositories? The first is a problem, the second is not.

Seems we can grant "write" permissions to the action, so any PR made will have preview,
but we need to be sure that in our org, we'll carefully check PR's content and aproove it to run. ( preferably for each org external fork PR, as it can create a bad html, read our org secrets and so on.)

The egui aproach created another organization just to handle previews, so they dont have the issue on their main repo/org permissions.

[ES-Alexander]

The approach we took in our docs previews may be viable here. Basically:

1. Use the pull_request event to trigger building, and upload the result as an artifact
   • This event has no access to secrets
2. Trigger another Action on completion of the PR one, and use that to download the artifact and upload its contents to AWS (or some other hosting service)
   • This step doesn't actually run anything from the PR, so secrets access is ok
   • The hosting service can be used to limit the access of whatever gets put there
3. Trigger another Action on PR close, to automatically delete the AWS listing

I'm not sure whether Cockpit's size would be a problem, or whether we'd want restrictions on the size of what can be uploaded (perhaps as a rejection option on the hosting side).

There would still be concerns that someone could use our process to store and host bad images / malicious files embedded within the previews (and the artifacts¹), but that's impossible to avoid without requiring an initial PR review prior to allowing building (including for every edit during the review period), which can be quite inconvenient for the iteration process - tradeoffs, as usual.

Footnotes

1. I've reduced the Artifact and log retention period for the docs from 90 down to 5 days to help mitigate this, since the artifacts are only used transiently while uploading the previews. I didn't set it shorter because it may be useful to access logs for a few days after a push if the build process fails or something. Cockpit could use a similar approach, but may need a longer period if we want people to be able to test in electron form (instead of just the hosted previews and existing BlueOS Extension docker images). ↩