Create a workspace that is associated with a specified pull request.
If no workspaces already exist for the given pull request, this creates a new workspace. Otherwise, the new changes are applied to the existing workspaces.
This endpoint uses the old terminology "workspace" instead of "sandbox" for backward compatability.
Here's an example to create/update a workspace from a pull request in the HotROD application. To simplify the use case, consider that only the Route Service had changes, and that the changes were published to an image file named signadot/hotrod-route and tag 4e75b0b822ecbbbb4c917b0fffeb337589d82456. This could be tagged as anything e.g. latest, e2e-test etc.
As a part of workspace creation, Signadot creates forked Kubernetes workloads (such as deployments) from existing workloads using the provided images. In order to access the forked workloads(s), endpoints are specified and corresponding to each endpoint, a preview URL is generated. These preview URLs are returned as part of the response. In the example below, we're dealing with a deployment named route in the hotrod namespace that is running the docker image signadot/hotrod-route.
In the below request to create a workspace, the deployment named route is forked and the fork will be created with the new docker image tag as specified by newTag. The new deployment that is created will be running the a new docker image tag as specified by newTag. There will be a single preview URL associated with this workspace as specified in endpoints and it will point to the fork of the route
deployment that was created.