Buildpacks Dockerfile RFC Tracking

[BarDweller]

This issue is to allow us to track the work happening in the Buildpacks community to deliver the 'Dockerfiles RFC'.

Links:

• Dockerfiles RFC : https://github.com/buildpacks/rfcs/pull/173
• Phase 1 tracking task : https://github.com/buildpacks/rfcs/issues/224

The buildpacks community is implementing the Dockerfile RFC as a series of stages.. (taken from RFC)

• Phase 1: run.Dockerfiles can be used to switch the runtime base image
• Phase 2: build.Dockerfiles can be used to extend the build time base image
  • 2a: pack applies the build.Dockerfiles
  • 2b: the lifecycle applies the build.Dockerfiles using kaniko
• Phase 3: run.Dockerfiles can be used to extend the runtime base image
  • 3a: pack applies the run.Dockerfiles
  • 3b: the lifecycle applies the run.Dockerfiles using kaniko

Our goal is to have UBI8 based builder/run images, where dependencies are installed via rpm/dnf. This will become possible for subsets of applications at Phase 2, with complete support requiring Phase 3.

Phase 1 is of little use to us, except for creation of small scoped PoC's to test the overall approach, and provide feedback to the buildpacks community.

[BarDweller]

Phase 1 may seem small to us from a functionality perspective, but Phase 1 to buildpacks is the introduction of the concepts surrounding 'extensions' which are the vehicles through which the Dockerfiles will be generated. As such, although Phase 1 offers us no real capabilities to make use of, it's still very worth being engaged, as it's now that the docs/specs are being updated to allow for the existence of extensions. This process takes times because really it's the first point at which the wider buildpack community is considering the implications of extensions, and slowly but surely anticipated problems are being discussed and resolved. This process has already resulted in changes to the spec since the PoC, with extensions gradually being treated as different entities to buildpacks, rather than just a different flavour.

[BarDweller]

Updates!

It took longer than expected, as a few issues had to be resolved. However, the current plan is now to release Phase 1 & 2 together.. the RFC has been accepted, and the lifecycle changes are currently being built in the branch https://github.com/buildpacks/lifecycle/tree/extensions-phase-2 which we are expecting to merge to main during September.

From the original list.. Phase 2a & 2b and 3a & 3b have been collapsed to just 2b & 3b respectively.

I've been testing the phase1+phase2 branch by composing my own builder image containing extensions, buildpacks, and the updated/patched lifecycle binaries, and it is looking functional.

Using such a builder image requires a platform implementation that is compliant to the upcoming platform version that supports that lifecycle. Or, in other words, this won't work with most existing platform implementations until they update.. I'm using a trivial implementation of a platform I've written in bash. The most notable difference from previous platforms is that (currently) you cannot use the single 'creator' lifecycle phase with builder images containing extensions, you have to drive the individual phases sequentially. I will be updating the quarkus buildpack library shortly to recognise & support these buildpacks. Support via 'pack' should follow shortly from the buildpack team.