On cluster build: Not working for a golang function

[Shashankft9]

I am following this doc: https://github.com/knative-sandbox/kn-plugin-func/blob/main/docs/guides/on-cluster-build.md and have compiled func cli from main branch.

I created function in go language.
When I am doing func deploy, it fails with:

Error: function pipeline run has failed, please inspect logs of Tekton PipelineRun "my-function-git-pipeline-run-d92n4"

Upon taking a look at step-create, it says:

Paketo Go Build Buildpack 0.6.0
  Executing build process
    Running 'go build -o /layers/paketo-buildpacks_go-build/targets/bin -buildmode pie -trimpath .'
      Failed after 94ms
        go build: no main packages to build
failed to execute 'go build': exit status 1
ERROR: failed to build: exit status 1

I wonder if its because go functions require some scaffolding with boson go buildpack and that might not be included in the create step of buildpacks task here: https://github.com/raw/tektoncd/catalog/master/task/buildpacks/0.3/buildpacks.yaml

[zroubalik]

@Shashankft9 you are right, that's the problem.

@lance did this PR: boson-project/packs#5

We just need to set the proper builder for Golang based func projects.

Willling to tackle this? Thanks!

[Shashankft9]

sure, related question - something like the PR you linked has to be done for rust runtime as well I believe? Since it uses one paketo community buildpack which is not included in the the paketo buildpacks builder.

Also, will there be more custom builders for future enhancements/new language runtimes? What are your opinions about somehow keeping the builder same across but adding and using buildpacks on need-basis? (if this is even possible with on cluster build support). I am thinking about what would happen if a provider already uses some custom buildpacks and they want to plug it in func builds. IIUC all this would be for on cluster builds only, since there is a way to plug in custom buildpacks in the func.yaml which can be used to do local builds.
I guess this above question could also be translated as (custom builders) vs (same builder + custom buildpacks) - whats the ideology around this here?

Sorry for the long edit, if you think this should be transferred somewhere else, I can do that as well - thank you!

[zroubalik]

sure, related question - something like the PR you linked has to be done for rust runtime as well I believe? Since it uses one paketo community buildpack which is not included in the the paketo buildpacks builder.

Do you think you can handle Rust as well? Thanks!

Also, will there be more custom builders for future enhancements/new language runtimes? What are your opinions about somehow keeping the builder same across but adding and using buildpacks on need-basis? (if this is even possible with on cluster build support). I am thinking about what would happen if a provider already uses some custom buildpacks and they want to plug it in func builds. IIUC all this would be for on cluster builds only, since there is a way to plug in custom buildpacks in the func.yaml which can be used to do local builds. I guess this above question could also be translated as (custom builders) vs (same builder + custom buildpacks) - whats the ideology around this here?

Sorry for the long edit, if you think this should be transferred somewhere else, I can do that as well - thank you!

This is a good question, we need to tackle this? Maybe the global configuration could solve this? Users could overwrite default buildpacks there? WDYT?

[Shashankft9]

Do you think you can handle Rust as well? Thanks!

Sure! but we will need to host the rust builder somewhere (ref: https://github.com/paketo-community/rust#a-builder), just like the go builder. I don't know how I can do that, any pointers?
Note: the rust builder also deletes the source files, so the PR #830 will unblock that.

This is a good question, we need to tackle this? Maybe the global configuration could solve this? Users could overwrite default buildpacks there? WDYT?

I think this might not be an immediate issue, but might come up for users later who are already familiar with buildpacks and want to use their custom ones in on cluster builds, maybe the global configuration work will address some of it - I will open a separate issue for this

[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.

[zroubalik]

/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.

[zroubalik]

/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.

[lance]

/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.

[lance]

/remove-lifecycle stale

[lance]

@jrangelramos do you think we can get an e2e test for this? I think it should work when using func deploy --builder=host.

[jrangelramos]

Yea. I think so. I can manage that.