Revisions and Building¶
Each uploaded deployment package is called a revision of a deployment version. Uploading a deployment package triggers a building process, which creates a container with the deployment code to start processing requests. Navigate to Revisions tab in the deployment version details page in the WebApp and click on the expansion button for a revision to get information about the builds of this revision, along with the status and a description of what triggered the build.
Uploading a deployment package triggers a building process, which creates an environment. This environment consists of a base environment and files specifying any additional dependencies. If you upload a deployment package with environment files inside, then automatically a custom environment is generated. The environment files can only be updated by uploading a new deployment package. It is not possible to directly substitute an automatically generated environment with another custom environment when editing the deployment version (that would lead to dependency conflicts). Changing the environment files is therefore only possible by uploading a new deployment package with different environment files. However, changing the base environment of a deployment version is always possible.After uploading a deployment package you can use the utils wait_for_.. functions to check if a deployment version, environment or revision has a succesful build:
| Function | Description | Example |
|---|---|---|
| wait_for_deployment_version | Wait for successful deployment version build | ubiops.utils.wait_for_deployment_version(core_api.api_client, project_name, deployment_name, version, revision_id=response.revision) |
| wait_for_environment | Wait for successful environment build | ubiops.utils.wait_for_environment(core_api.api_client, project_name, environment_name) |
| wait_for_revision | Wait for successful revision build to be available | ubiops.utils.wait_for_environment(core_api.api_client, project_name, environment_name) |
Note: you can find the full examples of these functions here.
It is possible to overwrite a deployment version with a new deployment package, this will trigger a new build and the history of updates will be visible in Revisions. After uploading UbiOps will check if there is an identical environment. If there is an identical environment UbiOps will use the existing environment and not build a new one.
If you upload a new deployment package to a deployment version, hereby overwriting the previous revision and triggering a new build, it could happen that the new build fails because of an error in the new deployment package. In this case the build status will be FAILED but the version can still be AVAILABLE as it reverts to the older revision with a successful build.
UbiOps maintains a full history of the ZIP packages uploaded to a version, which allows for tracing back the code that was deployed at any point in time. It is also possible to download the respective deployment package from the Revision history page in the WebApp.