lifecycle v0.7.2

lifecycle v0.7.2

Welcome to v0.7.2, a patch release of the Cloud Native Buildpack Lifecycle.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or tekton.

Bug Fixes

• Fixes error setting run-image with the CNB_RUN_IMAGE environment variable during export (#274, #275)
• More accurate error and warning messages (#276)

Known Issues

• creator is missing -skip-restore flag described in https://github.com/buildpacks/rfcs/blob/master/text/0026-lifecycle-all.md. This flag is necessary to disable the reuse of cached and launch layers from a previous build. (#287)

lifecycle v0.7.1

lifecycle v0.7.1

Welcome to v0.7.1, a patch release of the Cloud Native Buildpack Lifecycle. This patch fixes a critical issue in v0.7.0. Please do not use v0.7.0

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Bug Fixes

• When launching a process directly, apply layer modifications to the PATH before looking up the executable (#270)
• Checks more thoroughly for write permissions before attempting to fix volume ownership (#271, #273)

Known Issues

• creator is missing -skip-restore flag described in https://github.com/buildpacks/rfcs/blob/master/text/0026-lifecycle-all.md. This flag is necessary to disable the reuse of cached and launch layers from a previous build. (#287)

lifecycle v0.7.0

lifecycle v0.7.0

⚠️ Warning ⚠️

v0.7.0 is not spec compliant. It fails to find processes on the layer-modified PATH when direct=true. Please use v0.7.1 instead.

Welcome to v0.7.0, the seventh beta release of the Cloud Native Buildpack Lifecycle. This release introduces several new features as well as performance improvements and smaller lifecycle binaries.

Notice:

This release contains breaking changes which are detailed at the bottom of the release notes.

Implemented APIs

Platform API: 0.3
Buildpack API 0.2

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or tekton.

Features

• New creator binary allows all build phases to be executed in a single container (#243, RFC)
• buildpacks can use a store.toml file to persist specific metadata, even when the cache is cleared (#244, #256)
• -process-type can be used to set the default process during export (#260, RFC)
• -project-metadata flag allows users to add source metadata to image during export (#230)

Performance and Size Improvements

• lifecycle phases (excluding launcher) ship as a single multicall binary, reducing artifact size (#232, RFC)
• 4x smaller launcher binary (#247, #255)
• faster computation of layer hashes (#248)
• faster untar of cached layers during restore (#246)
• layer hashes are only calculated once (#242)

Bug Fixes

• layers generated by the buildpack are exported in lexical order (#250)
• an info message rather than a warning is printed by analyze during a first build (#251)

Breaking Changes

• Docker credential helper integration has been removed (#259, RFC)
• The platform must provide environment variables to buildpacks using /platform/env, rather than setting them directly in the lifecycle's environment. This brings it in compliance with the specification.

Deprecations

• -image flag on exporter is deprecated in favor of -run-image for clarity

Known Issues

• creator is missing -skip-restore flag described in https://github.com/buildpacks/rfcs/blob/master/text/0026-lifecycle-all.md. This flag is necessary to disable the reuse of cached and launch layers from a previous build. (#287)

lifecycle v0.6.1

lifecycle v0.6.1

Welcome to v0.6.1, a quick patch release of the Cloud Native Buildpack Lifecycle.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Features

Bugs

• The exporter will no longer try to delete your app directory under certain slice configurations (#240).

lifecycle v0.6.0

lifecycle v0.6.0

Welcome to v0.6.0, the sixth beta release of the Cloud Native Buildpack Lifecycle. This is a big release for us, including performance improvements, better metadata for built images, improvements to the reproducibility of images produced by the lifecycle, and more! Read on below to get the full details. Thanks a ton to everybody that contributed to this release.

Notice:

This release contains breaking changes which are detailed at the bottom of the release notes.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Features

• Breaking: Performance improvements! (#205, #207)
• App Slices! (#210)
• Lifecycle now verifies the platform API for compatibility when CNB_PLATFORM_API is set (#233)
• Further improvements to the reproducibility of builds (#226)
• Lifecycle rebasing is backwards compatible (#219)
• Lifecycle now includes processes in build metadata (#208)

Bugs

• Fix duplication of app directories in layer (#223)
• Fix the propagation of error when writing tars (#211)
• Lifecycle now takes umask into consideration when untarring (#203)

Breaking changes in this release:

Notice

TL;DR

This 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
• pack0.5.0cannot 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.

For any questions or concerns please reach out via mailing list or slack.

lifecycle v0.5.0

lifecycle v0.5.0

This is the fifth beta release of the Cloud Native Buildpack Lifecycle. This implementation should be relatively stable and reliable, but breaking changes in the underlying specification may be implemented without notice.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Features

• Add image rebasing to lifecycle (#185, #186).
• Improve logging, especially on Windows (#179, #184, #198, #183).
• Reduce size of lifecycle binaries by stripping symbols (#194).
• Adjust log levels (#187).

Bugs

• Add correct run image ref to image metadata (#200).
• Allow layers with read-only directories to be restored (#178).
• Improve layer order consistency when exporting images (#182).

lifecycle v0.4.0

lifecycle v0.4.0

This is the fourth beta release of the Cloud Native Buildpack Lifecycle. This implementation should be relatively stable and reliable, but breaking changes in the underlying specification may be implemented without notice.

NOTICE: This release contains breaking changes for buildpacks. See below.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Notice of Breaking Changes

This release contains breaking changes for buildpacks. While the latest version of the pack CLI remains compatible with this release, any buildpacks that ship with the release will need to be updated to match the following specification changes:
buildpacks/spec#55
buildpacks/spec#53
buildpacks/spec#52
buildpacks/spec#51

Additional context in these RFCs:
buildpacks/rfcs#20
buildpacks/rfcs#19
buildpacks/rfcs#15
buildpacks/rfcs#14
buildpacks/rfcs#12
buildpacks/rfcs#11

Features

General

• Update lifecycle archive format (#172).
• Update lifecycle paths to match spec (#169).
• Add launcher metadata to images (#160).
• Add correct buildpack metadata to images (#157).
• For image-based caching, use registry instead of daemon (#158).
• Add Bill-of-Materials to image metadata (#156).
• Respect CND_PROCESS_TYPE (#150).
• Add -version flag to lifecycle binaries (excluding launcher) (#151).

Specification-related changes

• Add lifecycle.toml containing supported contract versions to lifecycle bundle (#167).
• Refine interpretation of buildpack-provided env vars (#147).
• Load user-provided env vars by default (can disable via clear-env in buildpack.toml) (#163).
• Implement distribution specification (#154, #149).
• Implement contractual build plan (#149).
• Add support for bashless/scratch run images (#148).

lifecycle v0.3.0

lifecycle v0.3.0

This is the third beta release of the Cloud Native Buildpack Lifecycle. This implementation should be relatively stable and reliable, but breaking changes in the underlying specification may be implemented without notice.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Features

• Add support for exporting an image to multiple repositories or tags on the same registry (#140).
• Analyzer now permits skipping launch layer metadata restoration with -skip-layers flag.
• Avoid race conditions when previous image changes during the build (#20).

lifecycle v0.2.1

lifecycle v0.2.1

This is a patch to the second beta release of the Cloud Native Buildpack Lifecycle. This implementation should be relatively stable and reliable, but breaking changes in the underlying specification may be implemented without notice.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Fixes

• Fix critical bug that results in a failure to restore layer metadata to the correct location (#137).
• Move detection results to the beginning of each line (#134).

lifecycle v0.2.0

lifecycle v0.2.0

This is the second beta release of the Cloud Native Buildpack Lifecycle. This implementation should be relatively stable and reliable, but breaking changes in the underlying specification may be implemented without notice.

Prerequisites

The lifecycle runs as a normal user in a series of unprivileged Linux containers. To export images and cache image layers, it requires access to a Docker daemon or Docker registry.

Install

Extract the .tgz file and copy the lifecycle binaries into a build stack base image. The build image can then be orchestrated by a platform implementation such as the pack CLI or knative.

Key Features

• Implements Cloud Native Buildpack Specification as of buildpacks/spec@92a2673 as well as more recently added version constraints.
• Better error messages (#130, #135).
• Introduce launch-cache to improve performance when exporting to a daemon (#131 -> #132).
• Add Makefile (#129).
• Use stack.toml for run image (#127).
• Extract buildpack/imgutil package (#118 -> #125).
• Buildpack versions are constrained according to spec (#96).
• Support caching using volumes (e.g., PVCs) (#117, #120).
• Fix credential helper logic (#111).
• Improve logging for detection (#112).
• Add image creation time to images (#113).