Related to T287211: Figure out the future of (or replacements for) PipelineLib in a GitLab world, folks in Release-Engineering-Team have been discussing what the future of our image build toolchain might look like, whether we keep Release Pipeline (Blubber) around and continue to refactor it to satisfy use cases of ever-growing complexity, and figure out how to properly integrate it with GitLab, or if we instead evaluate Cloud Native Buildpacks as a possible replacement and standard for our image build toolchain in GitLab.

After hacking up a mind map today, the benefits of Buildpacks are apparent enough (vs. apparent drawbacks) that it's worth investing some time into a proof of concept.

Objectives

1. Assess implementation of existing WMF build processes representing both simple and complex build patterns.
   1. Can it handle building a simple service like blubberoid?
   2. Can it handle mediawiki image workflow efficiently including incremental builds?
2. Assess whether simple workloads can be expressed simply, complex ones coherently
3. Assess maintainability of builder images.
   1. One implemented, what does the cost of maintenance look like.
   2. Can implementation be shared/reused
4. Assess migration strategy
   1. Is it possible to implement a compatibility layer (a Blubber builder)?
   2. Would it be worth it or easier to just port blubber.yaml files?