An Instance for Each Pull Request

[cuihtlauac]

Currently, ocamlorg has two instances: ocaml.org (a.k.a. live) and staging.ocaml.org

Staging is ok, but it requires manual merges and rebases.

Whenever a PR is filled, the corresponding docker image is built, but only as a check. The resulting image is discarded. It would be nice to run those images if their build were successful. They would be updated at each git push to its branch and remain online as long as the corresponding PR isn't closed. URL could be something like pullsXXX.ocaml.org

That would automatically expose the changes proposed by each PR. Many PR wouldn't even have to be compiled locally to be reviewed. For instance, it would be the case for content and UI/UX changes. It would also allow us to check tricky issues such as the one raised by enabling git lfs.

EDIT: To save resources, it may make sense to bring online and offline pr instances manually, using a GH action triggered online. Project members with sufficient rights would bring pr instances up by entering the PR number in “Actions” and down by clicking inside a list of live instances.

[mtelvers]

This would be achievable with the ocurrent deployer pipeline.

We can’t automate changes to the DNS to ocaml.org for administrative reasons, so it would need to be in a different domain. We could potentially delegate pulls.ocaml.org to another DNS server and then have prXXX.pulls.ocaml.org.

We’d need sufficient resources to run the multiple instances of the website. I’d suggest that the ‘button’ to make the deployment active be part of the ocurrent pipeline rather than a GitHub action. However, initially, it might be worth just trying it to see how many resources are consumed by this. The website isn’t particularly resource intensive.

I would need to look in more detail at the webhooks associated with merging a PR and how this could be used to clear down the images when the PR is merged. If no suitable hook is available, we could just have a job running periodically to close any instances without a corresponding PR.

We could easily push the image to Docker Hub and pull it on the staging machine. Still, while it is more work, transferring the image directly to the machine running it would be cleaner or use a private Docker registry to facilitate the transfer to avoid a permanent record of all these images on Docker hub. Or, looking at it from the other way, you could create a pool of one machine (the staging machine) and use that for all the builds and hosting; then, there is no need to transfer the images.

[sabine]

Doing this as an ocurrent action and not a GitHub action would be perfectly reasonable - not all PRs need to be staged like that, but for those that do, it's very useful.