-
Notifications
You must be signed in to change notification settings - Fork 388
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Renameable binaries / path #944
Comments
This issue is stale because it has been open for 90 days with no |
Is there any update on this? I'd like to switch over to ko from docker's buildx, but I'm also facing the problem of using ko with pre-existing projects where the entrypoint may not change. |
Sorry for not responding earlier. I'm not opposed to this in general, but I'd like to understand a bit more what requirements are driving it. Is the problem that a runtime config might be specifying the image's entrypoint, and it breaks when migrating to build with Is there a reason the image's entrypoint can't be used directly, so that both the old buildx image and the new
|
If you use docker to build the images (multi-stage builds) then you build the binary in the builder step and copy the built binary to a specific location which also becomes the entry point. One has complete control over it. This is also then used to set the command in the k8s deployment yaml file. Now when moving to KO this changes as it decides to prefix the entry point with On the other hand we can just specify the |
As @unmarshall explained, having a fixed entrypoint poses the issue of breaking working systems and using ko as a drop-in replacement is not possible. Having the ability to change the default entrypoint would make adoption of ko into existing project much easier. In my particular case, I am writing a k8s operator with the operator framework and when building the bundle manifests it is not documented how to change the k8s |
I want to be clear that I'm not saying So there seem to be workarounds to this that (IMO) simplify the deployment config, since it removes config from the deployment manifest and makes the path of the entrypoint binary completely owned by the image build process. This is compatible with existing docker-based build workflows, and compatible with I understand it's a bit of a speedbump, but I think at the end of the road there's a cleaner deployment model where the deployment manifest doesn't have to know or care what the image's entrypoint is, and doesn't have to reiterate it when it's already defined elsewhere. |
ko
defaults to placing binaries into the path/ko-app/<app-name>
.As for now it seems as if there is no way to set this name during the build process.
This is especially important if the containers are used in a Kubernetes environment where the
entrypoint
is overwritten and the absolute path of the binary is important, which is a common practice.Although this path might be known it complicates the drop-in integration of
ko
containers in a production environment, since the deployments have to be adjusted to use theko
specific path.The lines responsible for the naming seem to be these.
It would be great if a new flag such as
-o
/--out-path
or something similar could be introduced that let the user set the output path to their needs.The text was updated successfully, but these errors were encountered: