Skip to main content
Version: Weekly Build

Static Builds Overview

A workspace builds its application on every deployment: it clones the repository, runs the prepare stage and starts the services. That is right while you develop. Once a version is finished, you want an immutable artifact that goes to production as it was tested, without a rebuild, and that can be handed to other teams or shipped to other Codesphere installations without access to the source repository.

A static build is that artifact. It packages one CI profile of a landscape into prebuilt container images and a run-only landscape configuration, and pushes both to a repository in a container registry of your choice under a tag. Use it to:

  • Release to production. Create a workspace from the artifact. It runs the prebuilt images, nothing is built.
  • Distribute a service. Publish the artifact as a managed service provider. Other teams, on this or another Codesphere installation, deploy it from the service catalog with one click.

Every consumer runs exactly the images that were exported, so a release behaves the same wherever it is deployed.

Static builds need the static-landscapes feature flag, creating workspaces from an artifact additionally the static-build-workspace-creation flag. See Feature Flags.

How it works​

You choose a CI profile and a target repository:tag, in the Landscape Config Editor or through the Public API. Codesphere runs the profile's prepare steps and each service's build steps in a workspace, builds one image per service and pushes everything to the target repository.

The repository then holds, under the tag you chose:

  • One image per reactive or container service. The base image named in the service's image field, plus the paths its build section copies in, plus the service's start command. Managed containers are copied into the repository as they are, so the artifact does not depend on their original registry. The landscape router is included too.
  • The run-only configuration. A copy of the profile with an empty prepare stage in which every service points at its image in the repository. Plans, replicas, ports, mounts and templated values such as ${{ vault.KEY }} are kept and resolve where the artifact is deployed. Managed services and virtual machines stay in the configuration unchanged and are provisioned by the installation that deploys it.

The reference registry.example.com/team-1/shop:v1 is the artifact. Consumers need nothing but read access to the repository.

Next steps​