Skip to content
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

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

Open
barnabasbusa opened this issue Feb 26, 2024 · 6 comments
Open

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

barnabasbusa opened this issue Feb 26, 2024 · 6 comments
Assignees
Labels
cli For bugs relating to the CLI feature request nice to have Nice to have feature

Comments

@barnabasbusa
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator Author

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
Copy link
Contributor

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;

@h4ck3rk3y h4ck3rk3y self-assigned this Aug 8, 2024
@samlaf
Copy link

samlaf commented Sep 24, 2024

+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: ethpandaops/optimism-package#69

@tedim52
Copy link
Contributor

tedim52 commented Oct 2, 2024

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
Copy link

samlaf commented Oct 2, 2024

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cli For bugs relating to the CLI feature request nice to have Nice to have feature
Projects
None yet
Development

No branches or pull requests

6 participants
@mieubrisse @h4ck3rk3y @samlaf @barnabasbusa @tedim52 and others