You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To manage PR created from fork repositories, the PR preview deployment is now done with 2 workflows.
The first workflow is triggered on the pull_request event. It build the site preview and upload it.
The 2nd workflow is triggered on a workflow_run event. It deploys the site built by the 1st workflow.
The run of the 1st workflow is linked to the PR in both the commit list and the checks.
However, this is harder for the 2nd workflow which is not linked to the PR. A PR comment is updated during the run but it is sometimes hard to see that the deployment is in progress.
Proposal
We could update the commit status (that trigger the build/deploy) to indicate the deployment preview status and then visually linked it to the PR:
pending when the 2nd workflow starts
success/error depending on the 2nd workflow execution
There is an GH API to update the commit status and various GH Actions exist to handle this. This can also be done using the GH CLI.
To manage PR created from fork repositories, the PR preview deployment is now done with 2 workflows.
pull_request
event. It build the site preview and upload it.workflow_run
event. It deploys the site built by the 1st workflow.The run of the 1st workflow is linked to the PR in both the commit list and the checks.
However, this is harder for the 2nd workflow which is not linked to the PR. A PR comment is updated during the run but it is sometimes hard to see that the deployment is in progress.
Proposal
We could update the commit status (that trigger the build/deploy) to indicate the deployment preview status and then visually linked it to the PR:
There is an GH API to update the commit status and various GH Actions exist to handle this. This can also be done using the GH CLI.
Technical suggestions
The proposed solution is inspired by https://github.com/docker-mailserver/docker-mailserver/pull/4264/files found in https://github.com/orgs/community/discussions/25220#discussioncomment-11285087.
We may have to be careful when retrieving the commit sha in the PR because of https://github.com/orgs/community/discussions/25220#discussioncomment-11206904
"The problem is github.event.workflow_run.pull_requests is empty when the PR is not from your repo but from a fork (which anyone unable to create a branch on your repo, like most contributors cannot, must fork the repo to create a PR)."
See also some additional information consolidated after discussion with GHSL (GH Security Labs): https://github.com/orgs/community/discussions/25220#discussioncomment-11316244
In the past, we already workaround it to get the PR number in workflow trigger by
workflow_run
events in afc163/surge-preview#294 and bonitasoft/actions@9ff741eThe workaround was taken from https://github.com/orgs/community/discussions/25220#discussioncomment-8697399
The text was updated successfully, but these errors were encountered: