Use single step for all four Buildpacks lifecycle phases

[SaschaSchwarze0]

FIxes #455

The change updates the buildstrategies for Buildpacks, Heroku as well as Paketo, to use a single step for the four lifecycle phases. It is inspired by the Tekton catalog entry for Buildpacks. It uses the functionality introduced by /cnb/lifecycle/creator.

I am using the resources of one old step now for the merged step.

I did some performance tests. The old build strategy assigns different resources to the different steps: prepare, detect and restore got 0.1 CPU cores and 128 MiB memory; build and export received 0.5 CPU cores and 512 MiB memory. The new build strategy with just one step for the Buildpacks lifecycle continued to assign 0.1 CPU cores and 128 MiB memory to the prepare step while the buildpacks step received 0.5 CPU cores and 512 MiB memory. The source code came from cf-acceptance-tests. The Buildpacks builder image was 0.1.35-full. I triggered ten buildruns at the same time. Four runtimes were tested:

Runtime	Old build strategy	New build strategy
Node	1m18.5s	1m14.6s
Go	3m20.7s	2m56.5s
Java	1m43.1s	1m33s
PHP	2m17s	2m12.6s

To confirm no difference with larger load, a single comparison with 30 parallel builds:

Runtime	Old build strategy	New build strategy
Java	2m57.7s	2m13.666666666s

[zhangtbj]

A quick question, do we need to update the buildpacks step in this ADR document?: https://github.com/shipwright-io/build/blob/master/docs/proposals/buildstrategy-steps-resources.md#example Or just keep as before is enough?

[SaschaSchwarze0]

A quick question, do we need to update the buildpacks step in this ADR document?: https://github.com/shipwright-io/build/blob/master/docs/proposals/buildstrategy-steps-resources.md#example Or just keep as before is enough?

Hm, good question. The proposal describes the distinction between strategy administrators and users, and discusses how we assign resources from the build strategy steps into container resources in the TaskRun. It also uses a buildpacks-v3-default strategy as a sample to help understanding it. The way the strategy looks, it does not match any existing build strategy (some steps have no resources, the buildpacks-v3 has resources for all steps also before I started modifying it, and they were the same for every step).

What do you think @qu1queee ? Should I update the sample in your proposal ?

[sbose78]

We could keep the proposal as is since this change doesn't fundamentally change how a BuildStrategy needs to be crafted.

[SaschaSchwarze0]

@sbose78 I added the performance comparison results to the PR description.

[qu1queee]

This looks good, not approving yet because either bot will merge this and there are two minor questions might be important. Can you pls add https://github.com/buildpacks/rfcs/blob/main/text/0026-lifecycle-all.md in your PR description pls, for future references.

[qu1queee]

Looks solid, thanks for the Verbesserung.

[qu1queee]

/lgtm
/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: qu1queee

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 [qu1queee]

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