Story

As a developer using Buildpacks on OpenShift I would like the ability to configure and use Bindings with Paketo Buildpacks to provide credentials and other secrets at build and runtime.

Background

Some Paketo Buildpacks and components installed by the Paketo Buildpacks accept credentials and other secrets using bindings at build and runtime. Commonly, bindings provide the location and credentials needed to connect to external services.

Some categories of external services one might want to bind at build-time include:

• Private artifact repositories.
• SaaS security scanning tools.

For example, the Maven buildpack accepts the location and credentials need to connect to a private Maven repository in a binding.

Some categories of external services one might want to bind at runtime include:

• APM servers.
• Data Services.
• OAuth2 providers.

For example, the Spring Boot Buildpack will install Spring Cloud Bindings(opens in a new tab) which is capable of auto-configuring Spring Boot application configuration properties to connect the application to a variety of external services, when a binding is provided at runtime.

Out of scope

• None

Approach

The upstream Shipwright API should be updated to include a section that allows for the configuration of Bindings that can be passed to the appropriate command when using buildpacks. See the Examples listed at https://paketo.io/docs/howto/configuration/#how-to-use-bindings for more information about how bindings are configured via each build command.

Dependencies

Acceptance Criteria

1. The ability to provide configuration options that will allow the use of Bindings when using Paketo Buildpacks.

INVEST Checklist

• Dependencies identified
• Blockers noted and expected delivery timelines set
• Design is implementable
• Acceptance criteria agreed upon
• Story estimated

Legend

• Unknown
• Verified
• Unsatisfied

Done Checklist

• Code is completed, reviewed, documented and checked in
• Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
• Continuous Delivery pipeline(s) is able to proceed with new code included
• Customer facing documentation, API docs etc. are produced/updated, reviewed and published
• Acceptance criteria are met