tbouffard
commented
1 month ago 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 https://github.com/benjaminParisel/surge-preview/pull/1
This custom implementation has been tested in a PR created from a fork repo, see https://github.com/process-analytics/github-actions-playground/pull/349. It has also been tested with PR created from the target repository, see https://github.com/process-analytics/github-actions-playground/pull/350.
We have check that the teardown could be managed in a specific workflow like in https://github.com/process-analytics/github-actions-playground/pull/351
A contribution has been proposed to the official surge-preview action https://github.com/afc163/surge-preview/pull/294 which is based on our experiment.
Next steps
To have a fully working solution
- [x] use the official surge-preview (or our own fork) including the proposed fix
- [x] 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;
- [x] 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 https://github.com/bonitasoft/actions/pull/131) - [x] 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.
- [x] 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).
- [x] do tests to build the site in a documentation content repository (for example, with
labs): https://github.com/bonitasoft/bonita-labs-doc/pull/159 + test with https://github.com/bonitasoft/bonita-labs-doc/pull/160 - Apply the changes to all content repositories
- [ ] bonita-doc
- [ ] bcd
- [x] bpi https://github.com/bonitasoft/bonita-process-insights-doc/pull/4
- [ ] central
- [ ] cloud
- [ ] test-toolkit
ℹ️ Part of a top-level initiative: #670
Currently, the preview is built and only attached as an artifact of the GH Actions run. It is not deployed to surge, so there is no live environment available. Be also aware of #402.
Current limitations
Resources
Possible solutions
Investigations
See https://github.com/bonitasoft/bonita-documentation-site/issues/686#issuecomment-2066683375. It also includes next steps.