|
1 | | -# earthly |
2 | | -A build system for inhabitants of planet earth |
| 1 | +# 🌎 Earthly - a build system for inhabitants of planet earth |
| 2 | + |
| 3 | +*Parallel, reproducible, consistent and portable builds for the same era as your code* |
| 4 | + |
| 5 | +## Why |
| 6 | + |
| 7 | +TODO: Simplify this by moving details into launch blog post. Keep only the essence here. |
| 8 | + |
| 9 | +Why does the world need a new build system? |
| 10 | + |
| 11 | +We live in an era of containers, CI/CD, automation, rich set of programming languages, varying code structures (mono/poly-repos) and open-source collaboration. None of the build systems out there serve well these new trends: |
| 12 | + |
| 13 | +* They don't take advantage of container-based isolation to make the builds portable |
| 14 | +* Builds are not easily reproducible - they often depend on already installed dependencies |
| 15 | +* They don't provide a way to import open-source recipes |
| 16 | +* Many are programming language-specific, making them unattractive to be used as a one-stop-shop |
| 17 | +* Parallelization ranges from difficult to almost impossible |
| 18 | +* Importing and reusability are primitive or difficult to use across repos |
| 19 | +* Caching is difficult to master, making it impossible to scale the build system in a mono-repo |
| 20 | +* They are difficult to use, leading to a build system guru situation (only one person knows how the build works) |
| 21 | +* Or a combination of the above. |
| 22 | + |
| 23 | +Of the popular choices out there, the options that come close are [Bazel](https://bazel.build/) and [Dockerfiles](https://docs.docker.com/engine/reference/builder/). Both are excellent, yet there are challenges: Bazel is difficult to adopt because it requires an all-in approach (are you ready to completely rewrite the build.gradle's in your org into [Bazel BUILD files](https://docs.bazel.build/versions/master/tutorial/java.html)?). Dockerfiles are great, but they only output images. You can subsequently use docker run commands and mounted volumes to output other kinds of artifacts - but that requires that you now wrap your docker builds into Makefiles or some other build system. |
| 24 | + |
| 25 | +Earthly accepts the reality that for some languages, the best build system is provided by the community of that language (like gradle, webpack, sbt etc), yet it adds the Dockerfile-like caching on top, plus more flexibility in defining hierarchies of dependencies for caching and reusability. |
| 26 | + |
| 27 | +### Benefits |
| 28 | + |
| 29 | +Here's what you get with Earthly: |
| 30 | + |
| 31 | +* Consistent environment between developers and with CI |
| 32 | +* Programming language agnostic |
| 33 | +* No need to install project-specific dependencies - the build is self-contained |
| 34 | +* First-party support for Docker |
| 35 | +* Syntax easy to understand even with no previous experience |
| 36 | +* Efficient use of caching, that is easy to understand by anyone |
| 37 | +* Simple parallelism, without the gnarly race conditions |
| 38 | +* Like a docker build but it can also yield classical artifacts (packages, binaries etc) |
| 39 | + owned by the user, not by root |
| 40 | +* Mono-repo friendly (reference targets within subdirs, with no strings attached) |
| 41 | +* Multi-repo friendly (reference targets in other repos just as easily) |
| 42 | +* In a complex setup, ability to trigger rebuild of only affected targets and tests |
| 43 | +* An import system that is easy to use and has no hidden implications |
| 44 | + |
| 45 | +## Dive in |
| 46 | + |
| 47 | +... TODO |
0 commit comments