working with private dependencies in functions

[Shashankft9]

trafficstars

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]

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]

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:

• will this file go directly in the func project structure?
• I also need to set GONOPROXY and GOPRIVATE, will this be possible too?

[benmathews]

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]

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

[github-actions[bot]]

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]

/remove-lifecycle stale

[github-actions[bot]]

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

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]

/reopen

[knative-prow[bot]]

@pierDipi: Reopened this issue.

In response to this:

/reopen

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-sigs/prow repository.