lcli docker

[BeroBurny]

Description

After release version 1.0.4 there is missing lcli in the docker image.
This tool is used for creating testnet configurations for lighthouse clients, and help developers who create tools around the beacon node and validator.

Version

stable - v1.0.4

Present Behaviour

lcli is missing command from docker.

Expected Behaviour

Able to use lcli without need to pull the entire project and set up a rust environment

Steps to resolve

return back lcli to docker build or create a separate docker image for lcli

[michaelsproul]

Are you also making use of the minimal spec? I had a quick browse of your ChainGuardian repo, and it seems you are?

We removed lcli (and the minimal spec) from the default build because they both consume a significant amount of compilation time on CI/CD, while being unused by almost all our users (PR here: #1989). As far as I understand our intention with lcli is that it's an unstable, mostly-internal tool, which is another reason not to provide it in the default Docker image (and have it depended upon).

I understand that this must be kind of frustrating for you. We could consider supplying lcli and minimal in our Docker builds again, but my preference would be for this to be maintained by the people who use/need it, with the understanding that lcli is unstable and could change without notice. In the period until the next stable release, would you mind experimenting with building lcli + minimal Lighthouse from source (possibly in a Docker image, if that's what you need), and we can re-assess the need to include it by default closer to the next release?

You can build lcli with make:

make install-lcli

Building Lighthouse with minimal spec support requires adding a feature flag:

cargo install --path lighthouse --force --locked --features spec-minimal

[BeroBurny]

Are you also making use of the minimal spec? I had a quick browse of your ChainGuardian repo, and it seems you are?

I'm working to update scripts that include moving to mainnet spec, as part of different branch and current code on the master will be removed

---

I'm aware that is an internal tool and unstable used for developing and testing that is the reason why I think the best solution is to build lcli to a separate Docker image, which is updated when needed. It will reduce build time and if a user wants to use a specific version can use a specific hash/tag and this will be pretty helpful for devs like me who do tooling around the ecosystem and onboarding new devs. It is simpler to run docker with an updated image that cloning/pulling and building client (harder for a user unfamiliar with rust and cargo)

[mpetrunic]

Are you also making use of the minimal spec? I had a quick browse of your ChainGuardian repo, and it seems you are?

I guess we only need lcli for creating testnet configuration and keys. We could write own little script to update genesis time.

We removed lcli (and the minimal spec) from the default build because they both consume a significant amount of compilation time on CI/CD, while being unused by almost all our users (PR here: #1989). As far as I understand our intention with lcli is that it's an unstable, mostly-internal tool, which is another reason not to provide it in the default Docker image (and have it depended upon).

Have you considered just creating another docker image with just lcli? That way, lighthouse build time would be independent of lcli. Also building image in github actions and pushing on dockerhub is significantly faster than building on dockerhub.

tbh I cannot even build lcli on my ubuntu machine but that's problem for another issue 😄

[michaelsproul]

Have you considered just creating another docker image with just lcli?

Yeah, I think based on the feedback in this issue this is a good way forward. We've just added some new configuration for building Docker images on Github, which as you said is so much better than relying on Docker Hub's builds. I'll see if I can add lcli to the mix for the next release (although if we miss the deadline it might need to live on unstable until the new year)

[paulhauner]

Another option is to add a Dockerfile to the lcli directory which would allow users to build the image themselves (without setting up a Rust dev env). I personally prefer this over setting up our own dockerhub repository for lcli.

[mpetrunic]

Another option is to add a Dockerfile to the lcli directory which would allow users to build the image themselves (without setting up a Rust dev env). I personally prefer this over setting up our own dockerhub repository for lcli.

That doesn't really solve anything. It's easy to create docker image for lcli, core issue is keeping it updated on code change in this repo 😄

[xaviarias]

Hi ! Is there any progress on this? Thanks