Provide a live preview for contributions done from fork repo

[tbouffard]

Provide a live preview for contributions done from fork repo

[tbouffard]

Investigations done in week 2024-04-17

Work done with @benjaminParisel

All tests have been done in the https://github.com/process-analytics/github-actions-playground/ repository with a fake site.

Experiment a solution with 2 steps as described in https://securitylab.github.com/research/github-actions-preventing-pwn-requests/

• first step build the site and upload an artifact (pull_request event)
• 2nd step (workflow_run event). The current implementation of the surge-preview action wasn't able to detect the PR number in this case. We have experiment a fix in benjaminParisel/surge-preview#1

This custom implementation has been tested in a PR created from a fork repo, see process-analytics/github-actions-playground#349. It has also been tested with PR created from the target repository, see process-analytics/github-actions-playground#350.

We have checked that the teardown could be managed in a specific workflow like in process-analytics/github-actions-playground#351

A contribution has been proposed to the official surge-preview action afc163/surge-preview#294 which is based on our experiment.

Next steps

To have a fully working solution

• use the official surge-preview (or our own fork) including the proposed fix
• decide if we want to manage the teardown in each PR. We have an workflow in the documentation-site repo that teardown old deployments --> decision: no, this simplifies the maintenance;
• update our surge-preview-tools (in the bonitasoft/actions repo) action to make it support workflow_run to get the PR number (same implementation as in the proposed fix) (see bonitasoft/actions#131)
• validate that the 2 steps build/deploy reusable workflows work. See #703
  • Notice that currently, the site is already uploaded as a workflow artifact. However, it doesn't use a fixed name. It currently include a part which relates to the job id. This is required when the action that build the site is used in the documentation-site repository: they are 2 jobs in the same workflow which upload the artifact so they cannot have the same name, see #676.
  • This will require that the documentation-site repository provides new shared actions or reusable workflows (see #700) to manage the multi-steps solutions (build then deploy, then create a PR comment with the details of changes). Currently, it provides a single actions that manages everything. See also #700.
• Manage PR content links in a dedicated reusable workflow: #715
  • This provides a better separation of concerns.
  • It also allows direct use of the existing custom action to be executed in a pull_request event context.
  • This will require managing an additional workflow in all content repositories, which will increase maintenance a little, but using a “reusable workflow” will limit the cost (mainly the cost at installation time).
  • It will be called in workflows triggered by the pull_request_target event (there is no build but only a check of files modified by the PR).
• do tests to build the site in a documentation content repository (for example, with labs): bonitasoft/bonita-labs-doc#159 + test with bonitasoft/bonita-labs-doc#160
• Apply the changes to all content repositories
  • bonita-doc bonitasoft/bonita-doc#2727
  • bcd bonitasoft/bonita-continuous-delivery-doc#226
  • bpi bonitasoft/bonita-process-insights-doc#4
  • central bonitasoft/bonita-central-doc#35
  • cloud bonitasoft/bonita-cloud-doc#60
  • test-toolkit bonitasoft/bonita-test-toolkit-doc#60

[tbouffard]

All tasks are completed, so closing