Add parameterized CNB_PLATFORM_API to buildpacks strategy

[dalbar]

Changes

Buildpacks defines versioned api specification that allows them to bridge the knowledge gap between the lifecycle and the independent buildpack implementations. More specifically it allows the lifecycle utility to enable features based on the known api version and thus staying backward-compatible.

The lifecycle utility receives the api version from the environment variable CNB_PLATFORM_API. Whenever this variable is not present, it assumes per default that the version is 0.3. Consequently, the lifecycle’s exporter ignores the default process determined in the build step and sets the entrypoint of the resulting image to the lifecycle’s launcher executable (code reference). The launcher itself is called without an argument and thus assumes that the default process is web.

The interactions above break simple programs such as https://github.com/IBM/CodeEngine/tree/main/job.

The PR proposes a minimum version of 0.4 based on evaluating the api version of all buildpacks in the paketo organization. The version introduces multicall-launchers and produces non-broken images for the example above.

For buildpacks that do not set a default process, the 0.3 version of the api assigned the web process as default. This is not producible with the previous approach of using creator and the version 0.4. Thus this PR splits the creator into its subcomponents to achieve a flexible point to inject the default process. As a side-effect, the changes remain compatible with paketo and heroku.

Submitter Checklist

• Includes tests if functionality changed/was added
• Includes docs if changes are user-facing
• Set a kind label on this PR
• Release notes block has been filled in, or marked NONE

See the contributor guide
for details on coding conventions, github and prow interactions, and the code review process.

Release Notes

The buildpacks strategy now assumes the version "0.4" as its platform api version. The buildpacks strategies are more granular in their build process and chose "web" as a default process.

/kind bug

[SaschaSchwarze0]

In Tekton Catalog, the version is also set to 0.4: https://github.com/tektoncd/catalog/blob/f4708d478ee8fac6b5b68347cde087cb7c1d1b1c/task/buildpacks/0.3/buildpacks.yaml#L65-L67

[SaschaSchwarze0]

Have you checked the Heroku buildpacks as well wrt their platform API versions?

[qu1queee]

From Grooming, @dalbar I think is fine to move here the additional changes you have in downstream.

[SaschaSchwarze0]

/approve
/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: SaschaSchwarze0

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [SaschaSchwarze0]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment