Pivotal Build Service (Alpha)
Page last updated:
This topic provides an overview of Pivotal Build Service (Alpha).
Note: To request early access to this Pivotal Build Service alpha release, contact Pivotal.
Warning: This release of Pivotal Build Service is not intended for use in a production environment. Features are subject to change without notice in future releases.
Pivotal Build Service uses the open-source Cloud Native Buildpacks project to turn app source code into container images. Build Service executes reproducible builds that align with modern container standards, and triggers builds when container dependencies change. You can use Build Service to develop containerized software securely and at scale.
For more information about the Cloud Native Buildpacks project, see the Cloud Native Buildpacks documentation.
For more information about modern container standards, see the Image Format Specification in the OCI Image Format Specification repository on GitHub.
Build Service reduces operational overhead and improves security by automating builds of container images for apps in your environment.
To organize container image builds, Build Service defines
project entities, as in the sections below. To define and modify configurations for
project entities, you can use the Build Service CLI,
image configurations are defined by
.yml files that include:
- The registry location of a built container image
- Source code for the image
- The project that owns the image
- Other configuration values, as described in the Image Configurations section of the Using the Pivotal Build Service CLI topic
If you change a field in an image configuration file and run
pb image apply with the file, Build Service rebuilds the container image based on its new configuration.
For more information about managing images in Build Service, see the Manage Images section of the Using the Pivotal Build Service CLI topic.
project configurations include:
The development team that owns container images, as managed by a User Account and Authentication (UAA) server
Container registries for the project’s images, and the registry credentials to access them
builderfile that defines the languages, buildpack versions, plugins, and other build configurations that the project uses
Build Service projects have the following constraints:
All members of a project are also project owners and are able to create new images, manage secrets, and add or remove other users from the project.
Only the users that belong to a project are able to create images against the project and check the builds against an image.
To add a user to a project, the user email address must exist in UAA.
You cannot use a previously existing UAA user group as a Build Service project. You must add users individually with
Each project must have at least one project member.
For more information about creating and managing projects in Build Service, see the Manage Projects section of the Using the Pivotal Build Service CLI topic.
For troubleshooting Build Service, contact Pivotal Support.