You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be great if the tool could support creating the service bindings for kpack.
Would it also be a volume mount to the builder?
Sofar I don't know how one would add the bindings of this sort via kpack.
Or could it look something like this, where "..." is the URI to the file (might also be an https URL)?
Please check out paketo-buildpacks/rfcs#302. I think this is going to be the path forward for most users with respect to dependency mapping. Please let me know though.
To move this one forward, i think I'd need to get some examples of what we need the tool to generate. I don't have kpack deployed, so I can't easily make them. If you give me some templates, it's pretty easy to make the tool generate them.
If my understanding is right ,currently pack users should use the --volume flag to mount a binding directory into the build or app containers. Users of the kpack platform should store key value pairs in a Kubernetes Secret and provide that secret and associated metadata to an Image as described in the kpack documentation(opens in a new tab).
Is binding tool going to supports creation of secrets in future ?
Basically i am looking for the tool to create binding for all the dependencies in the form of secrets like below. If the bt tool can provide secret file as an output it will very easy for kpack user to just create secret and build image.
What is your thought on how to tell the CLI you want it to generate the secrets file? I could add a flag to bt dm, like bt dm --k8s-secrets that when set would also write the secrets file.
Also, what is your thought on running the command multiple times? I suspect that we'd need to read the secrets file, locate the particular dependency mapping and then update it (if modified) or add new mappings to the list of mappings. Does that sound reasonable?
Sorry @doddisam I went to look at this again, and I'm not sure I follow in terms of what the value of the secret should be. In the example you provided, it's pointing to artifactory, which isn't really consistent with what the tool does now. It's purpose is to fetch from remote URLs and to generate a local folder structure that could be used as place from which to fetch the dependencies. Given that, the value would probably be file://... but I'm not sure what makes the most sense there in terms of K8s. What were you thinking?
I would also refer you back to #5 (comment) because if you're just trying to point your buildpacks to an artifactory cache that you have already set up, you can do that with the dependency mirror RFC, which has been implemented for all of the Java-based buildpacks.
Activity
doddisam commentedon Mar 28, 2024
@dmikusa - We are looking for similar feature, so is there any plan to get this in near future ?
dmikusa commentedon Mar 28, 2024
Please check out paketo-buildpacks/rfcs#302. I think this is going to be the path forward for most users with respect to dependency mapping. Please let me know though.
To move this one forward, i think I'd need to get some examples of what we need the tool to generate. I don't have kpack deployed, so I can't easily make them. If you give me some templates, it's pretty easy to make the tool generate them.
doddisam commentedon Mar 29, 2024
If my understanding is right ,currently pack users should use the --volume flag to mount a binding directory into the build or app containers. Users of the kpack platform should store key value pairs in a Kubernetes Secret and provide that secret and associated metadata to an Image as described in the kpack documentation(opens in a new tab).
Is binding tool going to supports creation of secrets in future ?
doddisam commentedon Apr 3, 2024
Basically i am looking for the tool to create binding for all the dependencies in the form of secrets like below. If the bt tool can provide secret file as an output it will very easy for kpack user to just create secret and build image.
doddisam commentedon Apr 15, 2024
@dmikusa - Can above format be possible from the bt tool ?
dmikusa commentedon Apr 15, 2024
Yes, the tool could definitely generate secrets.
What is your thought on how to tell the CLI you want it to generate the secrets file? I could add a flag to
bt dm, likebt dm --k8s-secretsthat when set would also write the secrets file.Also, what is your thought on running the command multiple times? I suspect that we'd need to read the secrets file, locate the particular dependency mapping and then update it (if modified) or add new mappings to the list of mappings. Does that sound reasonable?
doddisam commentedon Apr 15, 2024
Yes, Something like bt dm --k8s-secrets should work.
I think we can just add new mappings to the list when command is run multiple times.
doddisam commentedon May 16, 2024
@dmikusa Just checking if the above capability is added to the tool?
dmikusa commentedon May 26, 2024
Sorry @doddisam I went to look at this again, and I'm not sure I follow in terms of what the value of the secret should be. In the example you provided, it's pointing to artifactory, which isn't really consistent with what the tool does now. It's purpose is to fetch from remote URLs and to generate a local folder structure that could be used as place from which to fetch the dependencies. Given that, the value would probably be
file://...but I'm not sure what makes the most sense there in terms of K8s. What were you thinking?I would also refer you back to #5 (comment) because if you're just trying to point your buildpacks to an artifactory cache that you have already set up, you can do that with the dependency mirror RFC, which has been implemented for all of the Java-based buildpacks.
See https://paketo.io/docs/howto/configuration/#dependency-mirrors for docs on using that.
doddisam commentedon Jun 21, 2024
@dmikusa will dependency mirrors work for dotnet build pack also ?
dmikusa commentedon Jun 21, 2024
I believe that it should. It looks like packit implemented the RFC a few months back, see paketo-buildpacks/packit#563.
So long as that set of buildpack has updated packit to at least https://github.com/paketo-buildpacks/packit/releases/tag/v2.13.0.
I don't think there should be anything else that's needed.