Paketo Buildpacks integration

[qu1queee]

Idea:

The new collection(paketo) of cloud native buildpacks was announced today. As stated on the website, this buildpacks seem to be more:

• modular
• transparent
• written in go
• better performance(mainly on rebuilds)

while still implementing the Cloud Native Buildpacks specification, however they do not belong to CNCF(as the buildpacks project). I think this goes more into the vendor-neutrality rational.

It seems Paketo will be the standard in the future for Cloud Foundry buildpacks.

More information on Paketo:

• announcement
• docs
• mentioned on CF community call , go to minute 30:45
• paketo website

Having support for other types of buildpacks seems ideal for me. The list of current paketo buildpacks is in here

An experiment on how can we integrate this buildpacks with the Tekton task could be the next step, as an alternative for the buildpack builder. Opinions?

[sbose78]

Thanks, we should try this out.
We could add a "paketo-buildpacks" BuildStrategy.

[zhangtbj]

I think we could have some initial discussion next week first:

• Do we want to add a new "paketo-buildpacks" BuildStrategy
• Or replace the existing buildpacks BuildStrategy to use a more common or official builder?

[sbose78]

Ah I missed that this might be the standard one in future. Yes, if that's where we are heading to then paketo could be the the default one in our project too!

[otaviof]

Community notes:

• check how CloudFoundry makes possible to swap the base image;

[zhangtbj]

/assign @xiujuan95

[openshift-ci-robot]

@zhangtbj: GitHub didn't allow me to assign the following users: xiujuan95.

Note that only redhat-developer members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @xiujuan95

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[zhangtbj]

Can someone help add @xiujuan95 to this repo so that we can assign the issue to her?

And @xiujuan95 will continue to try to replace heroku builder image to paketo builder image (https://hub.docker.com/r/paketobuildpacks/builder/tags) in buildpacks-v3 build strategy and record if there is something wrong in each step first.

Thanks!

[zhangtbj]

As we know, the latest cloudfoundry buildpack also switch to paketo framework.

We can see the result from the latest cloudfoundry builder image:

Adding layer 'launcher'
Adding layer 'paketo-buildpacks/node-engine:node'
Adding layer 'paketo-buildpacks/npm:modules'
Adding 1/1 app layer(s)
Adding layer 'config'

So I think we can skip the cloudfoundry buildpacks and try the paketo buildpacks directly.

But let us also confirm that officially in future. Just FYI now.

[xiujuan95]

Currently, the experiment about replacing heroku to paketo is successful.

If we integrate paketo buildpack with tekton, then we need to make user 1000 own /tekton/home folder first. Because docker credential is stored in this folder. Next, at exporter step, we should make user 1000 to run this step instead of user 0.

Besides, for paketo, the credential helper parameter has be removed. So we don't need --helper=true parameter at export step.

[xiujuan95]

Compare heroku with paketo:

The most important difference is the version of lifecycle.

	heroku	paketo
lifecycle version	v0.6.1	v0.7.3
		- Docker credential helper has been removed ( --helpers=true )
		- Performance and Size Improvements
		- Platform API to be 0.3 instead of 0.2 ( a new lifecycle binary /cnb/lifecycle/creator )
		- project-metadata new feature (allow user to update image config using new source metadata during exporter step)
		- process-type new feature (allow user to change the default launch process in OCI image at export step)
code language	Bash nodejs example	GoLang nodejs example
supported buildpack	Java, Node.js, Go, PHP, Ruby, Python, Scala, Clojure	Java, Node.js, Go, PHP, .NET Core, NGINX. Ruby and Python (planned)

Besides, for your imformation:

All buildpacks packaged in CF for K8s will be Paketo Buildpacks. CF for K8s users can continue to have a similar buildpacks experience as they have on CF today.
All CF Buildpacks will continue to be supported for the foreseeable future. Over time, the currently supported major version line of each CF Buildpack will be deprecated in favor of a new CF-Compatible Paketo Buildpack. 

More Paketo buildpack FAQ

Hope above investigations can make sense for you!

[zhangtbj]

Nice summary @xiujuan95 !

Great thanks!

And we already verified to switch to use the Paketo buildpacks builder image in the buildpacks-v3 build strategy.

It works smoothly and e2e tests are passed.

Now, we have many buildpacks providers:

• Heroku
• CloudFoundry
• Paketo
• Google

So the buildpacks builder image which is based on the CNB standard should works well in our buildstrategy, but we need to discuss and confirm which one we would like to use.

[qu1queee]

Adding this to #174 for a short discussion. Lets keep this issue only for Paketo, and not add noise with all the other new options.

[zhangtbj]

Hi @xiujuan95 ,

Please go ahead to provide a PR to switch to use the paketo builder image in buildpacks-v3 buildstrategy.

Thanks!

[qu1queee]

This is already integrated, closing