Skip to content

Conversation

@rdimitrov
Copy link
Member

Motivation and Context

The following PR leverages ko instead of docker build for building the container image.

The motivation for the move is that ko has been one of the widely adopted ways to build Go applications, but overall its benefits are:

  • Build time is much faster - around 70-80%
  • The resulting image size is much smaller (also more secure) - around 50% smaller

The changes in this PR are:

  • Updated the workflows for staging and release to prod to use it
  • Updated the local development + the integration tests to use it (the integration tests overwrite the base image from chainguards one to alpine mostly because we rely on wget to check the health status and you don't get that in the stripped down one)

From the user point of view everything should continue to work as it is.

How Has This Been Tested?

Breaking Changes

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@domdomegg
Copy link
Member

Appreciate they both spit out OCI images, but I'm a bit nervous about moving to ko over Docker - feels potentially less standardized etc. than Docker.

Is the main benefit/motivation local dev speed? If so that's maybe reasonable and the trade-off is worth it. I'm not super convinced that image size / hardening is what we should be optimizing for rn if that's a key reason though.

@rdimitrov
Copy link
Member Author

There's the option to use ko for building the prod/staging images and continue to have docker for local builds, but I was concerned that this may introduce some risk of the two getting out of sync (although in our case it's not really that important since we build the project and set 3 variables).

Personally my main benefits are trying to improve the build time. Image size does help speed up deployment too but in this case I think it's insignificant.

domdomegg
domdomegg previously approved these changes Oct 27, 2025
Copy link
Member

@domdomegg domdomegg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

Would definitely prefer we use one system consistently throughout (e.g. if we're using ko locally, we should use it in production as well). My comment was more on the general move from docker -> ko.

Happy to go ahead with this given your reasoning.

@rdimitrov
Copy link
Member Author

Had to dismiss the approval as I noticed we are not including the seed.json as part of the image anymore so for local development we have to mount the data folder so the seed.json is available to the container.

@rdimitrov rdimitrov requested a review from domdomegg October 28, 2025 13:49
domdomegg
domdomegg previously approved these changes Oct 29, 2025
@domdomegg domdomegg enabled auto-merge (squash) October 29, 2025 13:23
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
Signed-off-by: Radoslav Dimitrov <radoslav@stacklok.com>
@domdomegg domdomegg merged commit b0a79c1 into main Oct 29, 2025
5 checks passed
@domdomegg domdomegg deleted the use-ko branch October 29, 2025 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants