kurtosis-tech / kurtosis

A platform for packaging and launching ephemeral backend stacks with a focus on approachability for the average developer.
https://docs.kurtosistech.com/
Apache License 2.0
376 stars 53 forks source link

FR: Be able to build any docker image using ImageBuildSpec #2215

Open barnabasbusa opened 8 months ago

barnabasbusa commented 8 months ago

Background & motivation

ImageBuildSpec is a great addition to kurtosis but currently its a bit limited.

It would be great if the buildspec would be able to support arbitrary urls and local paths. All services could then default to ImageBuildSpec instead of the current way of either local image or build an image. As this causes some issues for those that want to use the image building feature, without wanting to modify any starlark code.

Desired behaviour

If I don't specify path, it should use locally discovered image. e.g:

el_client_image: ethpandaops/geth

If you specify a local path, it should always build a new image based on the local repo e.g:

el_client_image: /local/path/to/Dockerfile

If you specify a remote url, it should use that Dockerfile to build a new docker image: e.g:

el_client_image: github.com/path/to/Dockerfile

How important is this to you?

Nice to have; this feature would make using Kurtosis more enjoyable.

What area of the product does this pertain to?

CLI: the Command Line Interface

mieubrisse commented 8 months ago

Hey @barnabasbusa , thanks for filing! Could you add clarification around the following:

All services could then default to ImageBuildSpec

Do you mean specifically services inside the ethereum-package?

barnabasbusa commented 8 months ago

I mean all services could use just imagebuildspec by default.

So instead of having

config = ServiceConfig(

    image = "kurtosistech/example-datastore-server",

    OR

    image = ImageSpec(
    )

    OR

    image = ImageBuildSpec(
    )

    OR

    image = NixBuildSpec(
    )

Give a bit more power for ImageBuildSpec and combine the features of all the other different spec into one, and make decisions based on what image_name is being passed.

I would much prefer if you merged all these different specs into one overarching doEverythingBuildSpec, which could use an image from dockerhub, could use an image from private repo, could build an image, or could build a nix image, all based on what you args you pass it. Maybe I'm trying to oversimplify things?

h4ck3rk3y commented 3 months ago

just cutting scope here -

I can add a GitHubImageBuildSpec that allows you to pass a GitHub path instead of the build_context_dir; I will let you handle the if conditions in the etheruem-package to figure out whether you use an Image or an ImageBuildSpec or a GitHubImageBuildSpec;

samlaf commented 1 month ago

+1 for this feature. Needed to build optimism docker images, since their main docker file is under a sub folder. PR waiting for this fix: https://github.com/ethpandaops/optimism-package/pull/69

tedim52 commented 1 month ago

Hey @samlaf ! Just took a look at the PR and revisiting this, to clarify, is the Dockerfile within the kurtosis package or outside the Kurtosis package? If it's the Kurtosis package (or can be put inside the Kurtosis package) this is a much lighter fix.

samlaf commented 1 month ago

@tedim52 do submodules count as being part of the kurtosis package? If so then yes, the docker file is at optimism/something/something/Dockerfile wrt kurtosis root, where optimism is the optimism repo as a submodule.