On-cluster build: Enable custom buildpacks

[zroubalik]

Currently there's no way how we can build a funcion on cluster with a custom buildpack.
For example Go runtime specifies these additional builpacks:

buildpacks:
- paketo-buildpacks/go-dist
- ghcr.io/boson-project/go-function-buildpack:tip

pack library used for local build handles this properly and pulls those additional builpacks.

Though /cnb/lifecycle/* binaries used by buildpack Tekton Task has only access to builpacks that are copyied into the buillder image:

 /cnb/lifecycle/creator --help
Usage of lifecycle:
  -buildpacks string
    	path to buildpacks directory (default "/cnb/buildpacks")
...

We probably need to pull and copy these builpacks to this directory before we initiate the build.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[lance]

/remove-lifecycle stale

[lance]

/kind feature-request

[grafvonb]

/assign

[matejvasek]

related: buildpacks/tekton-integration#30

[grafvonb]

Status quo:

• https://github.com/knative/func/blob/main/pipelines/resources/tekton/task/func-buildpacks/0.1/func-buildpacks.yaml
• https://github.com/tektoncd/catalog/blob/main/task/buildpacks/0.5/buildpacks.yaml

[grafvonb]

Our challenge here, in my opinion, is that from a UX perspective, switching between local and on-cluster builds by simply adding the --remote flag should be seamless for the user, i.e. provide the same functionality.

However, we use the pack library locally, while buildpacks Tekton Task uses the lifecycle directly, as mentioned by @zroubalik above (https://github.com/tektoncd/catalog/blob/main/task/buildpacks/0.5/buildpacks.yaml#L136), which does not provide "the power" of pack.

If we look at the ways buildpacks can be specified for pack (https://buildpacks.io/docs/app-developer-guide/specify-buildpacks/) and the implementation behind it (https://github.com/buildpacks/pack/tree/main/pkg/buildpack), it will take some time to recreate even the loading and extracting functionality for all the cases.

So, how do we deal with this issue? Maybe we should start small and initially just support one (it's better than nothing), simple URI format, like URL for the custom buildbacks, and extend our func-buildpacks.yaml accordingly?

[zroubalik]

@grafvonb you are right, my idea was to extend func-buildpacks Tekton task, so it will pull, extract and copy (we can probably use skopeo for this?) buildpacks from theirs images to some directory mounted to a volume. The lifecycle binary has a parameter that can point to a directory that contains additional buildpacks (so we just need to copy/link the additional buildpacks there). I concur this is not the nicest solution, but I haven't found anything better.

Btw there's some ongoing work to improve buildpacks on this front, not sure about the current status though: https://cloud-native.slack.com/archives/C032UM9DZV4/p1654790078405669?thread_ts=1654718175.599989&cid=C032UM9DZV4

[grafvonb]

@zroubalik ok, I got it. Should I start with an initial implementation?

[zroubalik]

@grafvonb it would be awesome if you can do so. Though might be worth checking that stuff I linked there ^, maybe there's some progress on that area that would enable us to use something nicer.

[grafvonb]

@zroubalik great, I'll do it. Could you please invite me to this slack workspace? Thx.

[grafvonb]

@grafvonb it would be awesome if you can do so. Though might be worth checking that stuff I linked there ^, maybe there's some progress on that area that would enable us to use something nicer.

@zroubalik very interesting, after 5 months the discussion about additional buildpacks support in Tekton's buildpacks task was started, yesterday came an update: https://cloud-native.slack.com/archives/C032UM9DZV4/p1667932092715799?thread_ts=1654718175.599989&cid=C032UM9DZV4. So there is no progress on this issue. Maybe we should take that over? Nevertheless, I will then start quite pragmatically with the first try for the scopeo solution.

[zroubalik]

agree, thanks!

[grafvonb]

Short update. The above discussion apparently ended a month ago with the sentence "I'll add the point to the agenda for the next one", which may simply mean "no-prio" status ;). As #1433 finally gets finalized I will get back to this topic.

[grafvonb]

I am back from vacation and continue to work on the solution.

[lance]

@grafvonb any updates here?

[grafvonb]

@lance sorry, there's no progress there; I was blocked by #1598 but I think it's closed now from the standpoint of initial development so I can get back to this topic.

[grafvonb]

For testing purposes of this issue, it would be nice to have #1466 implemented, so I'm working on that issue first.

[lance]

For testing purposes of this issue, it would be nice to have #1466 implemented, so I'm working on that issue first.

Thanks so much for your contributions @grafvonb!

[grafvonb]

Depends on #1466. Still in evaluation.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.

[matejvasek]

/remove-lifecycle stale

[github-actions]

This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.