Stages a patch against a development deployment
Persists a patch durably without applying it; call the sync endpoint to apply staged patches to the running deployment. The target must be a development deployment (its archive created with is_development set to true); patching any other deployment is rejected.
Authorizations
Send Authorization: Bearer <api_key>. The legacy Authorization: Api-Key <api_key> scheme is also accepted.
Body
A patch to stage against the development deployment.
Staging is durable on its own: the patch is persisted independently of the later sync, so a failed sync does not lose it.
Content hash of the patch point this patch is applied on - the link the staged patch must build on. A stale value (the base moved underneath the client) is rejected with a conflict.
The source state after this patch. The server derives its content hash from content_hashes.
The ordered ops that make up this patch. At least one op is required; a patch that changes nothing is not a valid request. There is no op for a directory: a directory comes into existence when the first file under it is added, and is removed when its last file is removed, so directory creation and deletion happen implicitly through the file ops. Adding or removing an otherwise empty directory therefore produces no ops even though it changes the source hash; do not send a patch request for such a change.
1Add, update, or remove a file under the model code directory.
- DeploymentPatchOpModelCodeV1
- DeploymentPatchOpPackageV1
- DeploymentPatchOpConfigV1
- DeploymentPatchOpPythonRequirementV1
- DeploymentPatchOpEnvVarV1
- DeploymentPatchOpExternalDataV1
Response
The created patch, represented by the patch point it produced.
The resulting patch point the staged patch produced; matches the pending point a subsequent state read returns.