Skip to content

Latest commit

 

History

History
134 lines (93 loc) · 6.97 KB

ROADMAP.md

File metadata and controls

134 lines (93 loc) · 6.97 KB
Raw

Roadmap

The Paketo Buildpacks project is focusing on 3 main themes that encompass our efforts for 2022: Improving and Expanding our Base Image / Stack / Builder Offering, Improving the Buildpack Authoring Experience, and Improvements to Dependency Management and Caching.

Improving and Expanding our Base Image / Stack / Builder Offering

RFC0045: Secure runtime environments

This RFC recommends that Paketo Buildpacks should in general strive to avoid making run-time modifications to the Buildpacks layers or the application directory by default. Instead, they should consider the output image to be read-only by default and explicitly set the parts that need to be writeable during runtime.

RFC0046: Define an Image & Dependency Retention Policy for Paketo Images

At the moment, the Paketo Project is maintaining images (buildpack, builder, stack, etc..) and hosted dependencies since the beginning of the project. This RFC proposes that we define an image and dependency retention policy that would allow the project to delete old images and dependencies.

stacks/RFC0004: Stacks based on Ubuntu 2022.04: Jammy Jellyfish

A set of stacks based on the Ubuntu 2022.04 LTS (Jammy Jellyfish) release base image should be developed, released, and maintained by the Stacks subteam. Like the existing Bionic stacks, these new stacks should come in "full", "base", and "tiny" variants with similar, if not identical, sets of packages pre-installed.

Improving the Buildpack Authoring Experience

RFC0040: Auto-generate Reference Documentation

We would like to make structural changes to the existing buildpacks repositories in order to facilitate the generation of automated documentation for each buildpack on the Paketo website.

Improvements to Dependency Management and Caching

Exploration: Buildpack Dependency Management Improvements

Many of the Paketo buildpacks contain references to dependencies that they will install during their build phase. These dependencies are often language runtimes like Ruby MRI or package managers like Poetry. The dependencies are tracked and built from their upstream source (dep-server) and updated in buildpacks (jam update-dependencies and dependency/update action) through a considerable amount of automation. This current architecture has outlived its utility and will likely present a significant technical headwind as we attempt to move buildpacks to new stacks.

Other Open RFCs

RFC0015: Distribute Buildpacks via Docker Hub

In addition to the current Google Container Registry (GCR) distribution channel, buildpacks should be distributed via Docker Hub.

RFC0017: Support HTTP Functions in the Go Buildpack

A Go buildpack that wraps an http.HandlerFunc in appropriate scaffolding to serve HTTP, and composes nicely with the existing go-build buildpacks.

RFC0019: Default Behaviour for Buildpack-Set Language Ecosystem Environment Variables

Paketo buildpacks sometimes use language ecosystem environment variables to configure build- and launch time behaviour. The environment variables' values can come a) from user input at build/launch time or b) from buildpacks' "opinions" about proper settings for the container build. If a user provides a language ecosystem environment variable at build time and the buildpack typically sets an opinionated build time value, the user's value should override or have precedence over the buildpack-set value. Likewise if a user provides a language ecosystem environment variable at launch time.

In addition, if a user provides a language-ecosystem environment variable at build time, that value should not be "sticky" -- it should not influence the launch time value of the environment variable. If a user wants to change the launch time value of an environment variable, they should provide it at launch time.

RFC0027: Common Logging Levels for Buildpacks

All Paketo buildpacks should provide a mechanism for tuning log verbosity. To enable this configuration, the buildpacks should respect a BP_LOG_LEVEL environment variable.

RFC0032: Reloadable Process Types

Provide a utility buildpack to support language buildpacks in creating reloadable process types for their run containers.

RFC0037: Remote Debug

The Java buildpack presently supports enabling remote debugging for applications. More buildpacks are looking to enable this functionality. It would be helpful to have a consistent set of environment variables used for enabling remote connections.

RFC0038: Support for CycloneDX and Syft SBoM in Paketo

Buildpacks which directly provide a dependency or buildpacks which install application dependencies will support the generation of SBoM in the format of CycloneDX and Syft. Per CNB RFC#95, the SBoM documents will live at <layer>.bom.<ext>.json, launch.bom.<ext>.json and build.bom.<ext>.json where <ext> will be cdx (CycloneDX) or syft (Syft).