[dmikusa]

Problem

A few implementation repos (jvm-vendors, build-tools) package a combined buildpack plus one buildpack per component. A separate workflow set would duplicate most of implementation and drift from it.

What changed

Multi-buildpack support is now opt-in in the standard implementation set. A repo adds a multi-implementation.json at its root describing the combined buildpack, components, images, and the libpak-tools command. Without that file, behavior is unchanged.

• create-draft-release has two gated paths: the existing single-buildpack release job, and a separate multi path (release-prep -> generate-notes -> release-multi). The single path is unchanged apart from the gate and needs.
• scripts/.util/implementation.sh loads the config into one normalized shape, synthesizing single-buildpack defaults in memory when the file is absent.
• package.sh uses libpak-tools when the config exists, otherwise the existing jam/pack path.
• push-buildpackage runs once per configured buildpack; a single repo is a one-item matrix.
• The has-warnings check is now shared in update-dependencies-from-metadata.

Verification

• scripts/sanity.sh, yamllint, shellcheck, and zizmor pass; actionlint reports no workflow-expression errors.
• The existing single-buildpack release job body is identical to main.
• Exercised config normalization and release asset naming for both layouts.

Follow-ups: switch jvm-vendors and build-tools to the implementation set and drop their local multi workflow copies.

Note

This PR was written by opencode and reviewed by a human.

[pacostas]

I guess the main reasons that is a different implementation are:

• Not making unrelated changes accross all the paketo buidpacks as this is related only to a very few repos
• The reconsolidation, would add as a fallback the single implementation which in terms of code readability does not make it very clear

My main concern is the maintenance of having two implementations where 95% are similar, as in case of a bug in one of the implementations, the other will not get benefited from the upcoming patch

[dmikusa]

Excellent catch there @pacostas. I just assumed there'd be too much difference, but turns out there really wasn't.

The separate multi-implementation set is gone and the behavior is folded into implementation, where things look for the presence of multi-implementation.json.

The single-buildpack create-draft-release job is unchanged apart from the config check and needs entries; multi repos get a separate job graph. push-buildpackage runs once per configured buildpack, and the warnings check is now in the shared update-dependencies-from-metadata workflow. This was the biggest change, because the multi workflow needs to dynamically set the matrix items (and has a matrix of what to release). I did it this way cause it doesn't change the existing implementation workflow. I could have combine them into one where the matrix set for the standard implementation is just a single item, but that seemed like a bigger change so I opted not to do that.

Mind taking another look?

[pacostas]

In terms of semantics, Im not really sure if the name implementation.sh gives an extra info to the developer, based on that should all the functionality of the implementation.sh be under the tools.sh and omit the implementation string from the name of each function?

[dmikusa]

Reworked the config loading so the defaults live in one place: util::implementation::config now normalizes multi-implementation.json into a single shape, and synthesizes that same shape in memory when the file is absent. The individual helpers just read the normalized config, so there are no per-field fallbacks scattered through the scripts. No default config file is checked in. Moved repo-name out to tools.sh as well.