Cloud (Foundry) Native Buildpacks

This is a spike on a tool to repackage Cloud Native Buildpacks as Cloud Foundry Buildpacks.

Usage

1. Download a CNB buildpackage (eg. a Ruby release).
2. Download a lifecycle.
3. Run

   package.sh \
     --buildpack /path/to/buildpackage.cnb \
     --lifecycle /path/to/lifecycle.tgz \
     --output /tmp/buildpack.zip
   

4. Upload the created buildpack to a Cloud Foundry.
5. Push your app.

Questions for further investigation

1. What is the contract for config.yml? This supports name and version, but some buildpacks include extra config:
   • https://github.com/cloudfoundry/go-buildpack/blob/75249ca38f80370112c9d2aec7a2061fef1f4e97/src/go/supply/supply.go#L241-L257
   • https://github.com/cloudfoundry/dotnet-core-buildpack/blob/afb2a62e3a915c203cc02d9de53f1a100693100a/src/dotnetcore/supply/supply.go#L371
2. What should we do about the cache?

Supporting VCAP_SERVICES

The current buildpacks have support for reading the VCAP_SERVICES environment variable, but only so that they can support integrations by third-party vendors. Below is a survey of the buildpacks we maintain today that reference VCAP_SERVICES and how they use it.

Python

• AppDynamics Hook
• Dynatrace Hook

Go

• AppDynamics Hook
• Dynatrace Hook

Node.js

• AppDynamics Profile Script
• Contrast Security Hook
• Dynatrace Hook
• NewRelic Profile Script
• Seeker Agent Hook
• Snyk Hook

.Net Core

• Dynatrace Hook

Staticfile

• Dynatrace Hook

Supporting override.yml

The override.yml feature allows users to override values in the buildpack manifest. This is mostly to include their own dependencies or override the default values. To use the feature, users will create their own buildpack that contains an override.yml file. This buildpack will then be included in the build prior to the buildpack that it overrides. When the buildpack executes it will simply copy its override.yml into its designated dependencies directory. Later, when the buildpack that will be overridden executes, it searches the entire dependencies directory for any override.yml file that may override its manifest and then overrides its manifest to include these new settings. Once it has overridden the manifest, it continues execution as normal.

It is not clear what the impact of not including this in our implementation might be. The shimmed buildpacks will not have a manifest.yml file that can be overridden. Instead, we would need to map this to something like our existing dependency mapping functionality.