knative / func

Knative Functions client API and CLI
Apache License 2.0
274 stars 138 forks source link

working with private dependencies in functions #1601

Open Shashankft9 opened 1 year ago

Shashankft9 commented 1 year ago

I came across a use-case where I had to use a private git repo as a go import, the git repo had some APIs. Usually, I can just change my gitconfig file to include the creds and go will include them while building the binary. Is it possible to do the same in functions (or buildpacks maybe)?

lkingland commented 1 year ago

There is not anything stopping us from sending the .gitconfig along with the source code for the build, however we would want to implement an explicit directive to ingore this file when actually building the contents of the container image so that those credentials are not part of the final container. This is part of a larger effort which is underway to implement a general-purpose ignore file for what gets included in the container (#1463)

We are not actively working on supporting referenced private dependencies at this time, though it is something we do intend to support. Have you considered vendoring the dependencies before it is sent to the builder, such that it need not reach out over the network at build time?

Shashankft9 commented 1 year ago

I tried the latest func, and did the vendoring, but seems like I am getting the same issue while the image is being built - is this expected?

I can try the gitconfig solution just to check the feasibility, some dumb questions:

benmathews commented 1 year ago

I don't see that running go mod vendor before kn func build has any effect on the error.

Importing private code seems a fundamental requirement for any business to use KNative. I would love to push for adoption by my company, but without this ability, I can't even start the conversation.

pierDipi commented 9 months ago

For reference, Buildpacks added support for this in https://github.com/paketo-buildpacks/go-mod-vendor/issues/140

github-actions[bot] commented 6 months ago

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.

pierDipi commented 6 months ago

/remove-lifecycle stale

github-actions[bot] commented 3 months ago

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[bot] commented 1 week ago

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.