I don't think it is meant to replace any particular build system like Bazel or make. Rather it is a better dependency glue flavor for Docker image building and testing. Earthly uses Makefile-like targets which can be leveraged through more advanced references [0]... essentially can replace plain "copy --from=" with a new magic strings syntax which also understand git. Build systems like Bazel would be invoked within a container.

I don't think the "why" using it instead of Bazel (and its plugins) will become clear until the Earthly SaaS gets announced that is hinted about in their TOS [1]. Build resource pool management, image release management, testing/dev environment definitions, custom URLs to test pull requests as seen elsewhere?

Arguably one could say they'd probably be able do the same thing by writing some Skylark and use remote build execution, but that could be close to saying Dropbox wasn't special in a Show HN thread. :-)

[0] https://docs.earthly.dev/docs/guides/target-ref

[1] https://earthly.dev/tos

I use earthly. I would not use it instead of bazel, but with bazel. You can imagine earthly working by building a DAG of docker commands (RUN, ENV, ...), similar to how bazel/make make one on your source files. If A depends on B and B changes, B then A are built, etc.

So keep bazel for building and testing, but you can use earthly to run above it so every bazel build is in a fresh docker container. Example:

    # All image deps
    RUN apt install -y bazel gcc
    
    build:
     RUN bazel build
    
    test:
     FROM +build
     RUN bazel test
    
    release:
     FROM +build
     RUN bazel package
     SAVE ARTIFACT AS LOCAL ./a.out a.out
     SAVE IMAGE cool-app:latest

Basel build runs before the other two targets, but testing and packaging run in parallel. I do this for elixir projects -- npm install assets and mix deps.get in parallel, then copy both results into the final image.

Edit: you can also inject arguments and the dependency graph will fork when needed. So for example, I can specify multiple version targets and earthly will only start running in parallel when it hits the build arg line (since subsequent run lines will have different build arguments)

The best summary from them looks to be:

> Overall, compared to Bazel, Earthly sacrifices some correctness and reproducibility in favor of significantly better usability and composability with existing open-source technologies

Exactly how much correctness is getting sacrificed is pretty important. A key insight of Bazel is that you can’t have speed at scale without correctness.

Would be good to have Earthly described within the framework of “Build Systems a la Carte”.

I had the same thought, and found this:

https://github.com/earthly/earthly#how-is-earthly-different-...

Same question here too!