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 toRevisions 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.
During building, the required packages for the deployment are installed, an instance that will handle the requests is deployed and the deployment is initialised. During the building process, the build status can take on the following values:
| Status | Explanation |
|---|---|
queued | The building has not started yet, there are no available builders at the moment. |
building | The building has started. The deployment package is validated, requirements and additional software packages are installed and a Docker image is created containing them. |
deploying | The Docker image is being deployed. |
validating | The deployment code is being validated by checking if initialisation of the deployment class succeeds. |
failed | The building has failed, check the error message of the build and the logs for more information. The version will be unavailable. The building might fail because of errors in the deployment file or during initialisation of the deployment class. No requests can be made to an unavailable version. |
success | The building has succeeded, the version will be available meaning that it is now possible to make requests to the deployment version. |
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.
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.