Pivotal Build Service (Alpha)

Page last updated:

This topic provides an overview of Pivotal Build Service (Alpha).

To request early access to this Pivotal Build Service alpha release, please contact us here.
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.

Overview

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 Cloud Native Buildpacks.

For more information about modern container standards, see Open Container Initiative in Github.

Image and Team Configurations

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 image and team entities, as described below. To define and modify configurations for image and team entities, you can use the Build Service CLI, pb.

Build Service Images

Build Service image configurations are defined by .yml files that include:

  • The registry location of a built container image
  • Source code for the image
  • The team that owns the image
  • Other configuration values, as described in Image Configurations

If you change a field in an image configuration file, for example by updating a buildpack version or source branch in git, 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 Manage Images.

Build Service Teams

Build Service team configurations include:

  • The development team that owns container images, as managed by a UAA server
  • Container registries for the team’s images, and the registry credentials to access them
  • A builder file that defines the languages, buildpack versions, plugins, and other build configurations that the team uses

Build Service teams have the following constraints:

  • All members of a team are also team owners and are able to create new images, manage secrets, and add or remove other users from the team.
  • Only the users that belong to a team are able to create images against the team and check the builds against an image.
  • To add a user to a team, the user email address must exist in UAA.
  • You cannot use a previously existing UAA user group as a Build Service team. You need to add users individually with pb team commands.
  • Each team must have at least one team member.

For more information about creating and managing teams in Build Service, see Manage Teams.

Troubleshooting

For troubleshooting Build Service, contact the Build Service team.