Hello Buildpacks community. We’d like to share some updates from the past month.  

Releases

• Lifecycle v0.7.2

• Pack v0.9.0

• CircleCI Orb 0.1.1

RFCs

• Finalized RFC-0029: Buildpack homepage

• Finalized RFC-0030: RFC template changes

• Finalized RFC-0031: Defining Mixins for io.buildpacks.stacks.bionic

• Final Comment Period for PR #66: Update JSON schema in CNB Registry

Community

• Spaceship launches with support for Cloud Native Buildpacks

• The Google Summer of Code application period is closed. We received a number of proposals and will review them this month.

Resources

• New CircleCI Orb for Cloud Native Buildpacks

• Getting Started with Cloud Native Buildpacks by Cora Iberkleid on KataKoda

Summary

New platform API 0.3 will be available after the release of lifecycle 0.7.0.

Platform API 0.3 comes with the following changes:

1. Added support for project-metadata.toml. (#230)

2. Added support for /lifecycle/creator. (#243)

3. Added support for -process-type flag. (#260)

4. [Breaking] Removal of the -helpers flag. (#259)

Platforms

In general, platforms should ensure that they support the stated changes to be compliant with Platform API 0.3.

Tekton

An update to the Tekton task will be available per issue #194.

pack

Added support for Platform API 0.3

pack will be compatible with Platform API 0.3 although it will not yet take advantage of all the new features. (#509)

Dropping support of Platform API 0.1

The platform team aims to always provide support for n-1 of the platform API and buildpack API versions. Given that a new platform API version (0.3) is available, we found it reasonable to drop support for platform API 0.1. (#509)

For more detail on what the changes are between platform API 0.1 and 0.2 please refer to the prior notice.

Builders

No impact to builders is expected.

Buildpacks

No impact to buildpacks is expected.

Hello!

The Cloud Native Buildpacks team is scheduled to release a new version of the lifecycle. The release contains some changes we want to make the community aware of in advance.

Summary

The next release of the lifecycle (0.6.0) contains changes which improve caching performance. These improvements introduce some breaking changes between the lifecycle and previous platform APIs. 

Builders containing the 0.5.0 version of the lifecycle will continue to work with newer versions of pack. This is the default version (as of pack 0.6.0) injected during the builder creation process. 

Explicit configuration of the lifecycle.version field to 0.5.0 during builder creation will allow you take the time to update to the latest changes. We plan to update the default version of the lifecycle to 0.6.0 at a later release of pack.

In order to maintain platform compatibility, platforms will need to implement the changes noted below.

Changes

There are 3 major changes that impact backwards compatibility.

1. `cacher` is now part of `exporter`. (#205)

• Impact: Major

• The `cacher` binary is no longer present. Refer to RFC#14 for details.

2. `analyzer` and `restorer` order of operations swap. (#207)

• Impact: Major

• The order in which `analyzer` and `restorer` are executed must be inverted. Refer to RFC#14 for details.

3. Implementation of App Slices as detailed in spec. (#210, #220)

• Impact: Minor

• A key on a metadata label used by the lifecycle has changed from a string to an array to align with the fact that there are now multiple application layers due to slices.

Impact

Platforms

Due to these breaking changes the Platform API version is being updated to 0.2. Platforms that support arbitrary builders should attempt to support both Platform API versions 0.1 and 0.2 for a transitional period. Platform authors can do this by supporting both the old and new build sequences/binaries, and selecting the proper sequence based on the lifecycle's declared API version. A platform can read a given lifecycle's declared platform API version by inspecting the io.buildpacks.builder.metadata label on a builder (lifecycle.api.platform field).

pack

pack 0.6.0 was updated (#384, #415, #423) to support both Platform API 0.1 and 0.2.

There is a minor constraint brought upon by the App Slices changes:

• pack 0.6.0 can rebase app images from lifecycle greater than or equal to 0.5.0

• pack 0.5.0 cannot rebase app images from lifecycle 0.6.0

Tekton

The tekton task will be updated to support only Platform API 0.2 in the coming weeks. (#176)

Buildpacks

There is no impact on buildpacks.

Builders

Since builders have an embedded lifecycle with a specific supported Platform API version, if the platform in which these builders are used does not support their provided Platform API version errors are expected. Builders can be created with an explicit Lifecycle version, which allows you to pin to a version of the lifecycle if your platform does not yet support the newest lifecycle. This is documented here.

Hello, mailing list readers!  

My name is Matt Gibson and I work as a PM on the Cloud Native Buildpacks project. Hopefully by this point you’ve visited https://buildpacks.io/, reviewed some of our documentation, and started to play around with the ‘pack’ CLI.  As always, we’re happy to answer questions, resolve issues, and listen to suggestions for how to improve @ slack.buildpacks.io.

While we're still excited about the beta release mentioned above, we also wanted to share an update about the CNB summit last month. On 3/20, core project contributors and platform stakeholders potentially seeking to integrate with CNBs gathered in Pivotal’s New York office to discuss future areas of focus for the project.  Others invited were maintainers of existing buildpack or buildpack-like integrations. During the meetings, the core project contributors solicited and prioritized feedback related to contributing to and using CNBs, the feasibility of various platform integrations, and to set up a more robust governance framework to better accommodate a growing community. We will review each of these areas in more detail below.  

Attendee List:

Scott Andrews (Project Riff)

**Emily Casey (Cloud Native Buildpacks)

Jacques Chester (formerly Cloud Native Buildpacks)

Daniella Corricelli (Cloud Foundry Windows)

Matt Gibson (Cloud Native Buildpacks)

*Joe Kutner (Cloud Native Buildpacks + Heroku)

Jose Gonzalez (Herokuish/Dokku)

*Ben Hale (Cloud Native Buildpacks + Cloud Foundry)

Daniel Joyce (Cloud Native Buildpacks)

Guillermo Kardolus (Cloud Foundry)

*Terence Lee (Cloud Native Buildpacks + Heroku)

*Stephen Levine (Cloud Native Buildpacks + Cloud Foundry)

Matt McNew (Cloud Native Buildpacks)

Andrew Meyer (Cloud Native Buildpacks)

Michelle Noorali (Draft + CNAB)

Joao Pereira (Cloud Native Buildpacks)

Ashwin Venkatesh (Cloud Native Buildpacks)

Micha Young (Cloud Foundry Windows)

* Project Owner

** Core Maintainer

Community Feedback

Collecting feedback from the community using and contributing to CNBs was a primary goal for the summit.  At various points, all attendees silently generated feedback on sticky notes, these notes were then affinity mapped based on the topic, and voted on by the group in an effort to prioritize the project’s focus.  UX, buildpack groups, and onboarding were the clear winners. To dig a little bit deeper on each of these categories, see below for some examples of the feedback we collected.

UX:

• “When I get an error, it’s really difficult to know why”

• “All the different metadata can be hard to keep track of”

• “Unclear who is the primary user of pack CLI”

Buildpack Groups:

• “Difficult to distribute buildpack groups”

• “Buildpack groups can be complicated”

• “Sharing groups is not well defined”

Onboarding:

• “How do I know which commands are meant for which persona?”

• “Getting started documentation could be better”

• “New to docker, the struggle is real”

We found this feedback extremely helpful, action items arising from this exercise have already influenced the work we’ve prioritized.  

• Andrew Meyer (Pivotal) updated the read me in the CNB repo and created a new tutorial based around using CNBs to create an image from a simple Java app and running it on a cloud platform

• We recently added a UX designer to the team who will focus on improving the pack CLI.  Additionally, the CNB team pulled more stories around improving the UX into the Beta release including - limiting the amount of generated image shas, making `pack inspect builder` more helpful, and more gracefully handling exiting a command when an image is pulling.

• Incoming PR that modifies the specification to improve the buildpack groups experience

Platform Integrations

In addition to collecting feedback, we wanted to take the opportunity presented by gathering in person to work through potential platform integrations.  Representatives from Draft, Dokku, and the Cloud Foundry Windows .NET experience team paired with at least one core CNB project contributor to work through a technical implementation for each platform.  Here’s a snapshot of some of the things we learned:

• Fewer barriers than anticipated to integrate CNBs with the Draft platform

• Pack as a library would probably help platforms come up with integration strategies more easily

• Mixins would be a huge help for Dokku and we should probably prioritize them following release of the CNB Beta

Governance

In 2019 we aim to grow the community by pursuing new platform integrations and adding more contributors and maintainers from a more diverse range of companies.  As we seek to add new voices, it is important to establish a more robust and well documented governance framework. Michelle Noorali of the Microsoft Draft team provided a lot of helpful feedback and shared insight into how more mature CNCF projects structure their governance.  Terence Lee captured the updates to our governance in a write-up, feel free to check it out and leave feedback!  

Thanks for reading!  Stay tuned for further updates.

Best,

The Cloud Native Buildpacks Team