11–20 of 38 posts
Nice. Been looking for something like this - a Dockerfile equivalent that isn't governed by the Docker folks, with whom I generally do not see eye to eye with. Bookmarked for later. Glad someone is thinking about this problem space!
I tried using Earthly, great product. Unfortunately, we rejected it at our organization due to how verbose the commands are. I want my users to be able to say `earthly plan-stage` for a terraform repo, and for it to work. But you cannot. You cannot have earthly automatically use environment variables from your env, you have to explicitly list the commands yourself using flags: $ earthly \ --build-arg AWS_ACCESS_KEY_I…
I think you’re better of using something like taskfile w/ earthly for a really good workflow, it gives you the best of both worlds.
(Actually I think I saw this on their slack)
Nice. Been looking for something like this - a Dockerfile equivalent that isn't governed by the Docker folks, with whom I generally do not see eye to eye with. Bookmarked for later. Glad someone is thinking about this problem space!
What is your gripe with the Docker folks?
Just my opinions.
I love earthly! It has been a joy to use. One thing I haven’t gotten right is caching. Some of my builds have targets they depend on that are very expensive but rarely change, and I haven’t been able to make sense of when those targets are (re)computed and when they aren’t. This results in many builds taking a long time, when the targets could be reused from a cache. Earthly is also missing something that I find to b…
The `earthly ls` idea is great. We do have shell autocompletions but that is not quite the same thing. I will add a ticket for that. Cache misses can be a bit inscrutable. It could be the buildkit GC is running, because disk space is getting scarce, or that some arg or file change caused the cache to be considered invalid. Caching is an area we will continue to improve. We have a proposal for extended cache mounts he…
> This helps avoid cases where tweaks to the CI script take long interaction cycles to test (git commit -m "try again..." anyone?)
Now you have my attention. I haven't done much CI work and the long iteration times are the main reason why. I have to edit a file, commit, push, wait for CI to start, wait for CI to complete, search through 10k lines of logs to find the error, repeat... seriously? This is the best we can do? I assumed that I was missing something.
I should be able to just `gh run-ci` in a repository on my machine. Or take one of those fancy online dev environments that everyone's making now and specialize it for editing CI files. Open an editor, let me click Run to run CI on-demand, have live error messages for syntax and missing variables, show a pane with a description of the CI jobs, show what config options are available for each job as it's being edited. Then once the changes are working I can commit and open a PR.
I tried using Earthly, great product. Unfortunately, we rejected it at our organization due to how verbose the commands are. I want my users to be able to say `earthly plan-stage` for a terraform repo, and for it to work. But you cannot. You cannot have earthly automatically use environment variables from your env, you have to explicitly list the commands yourself using flags: $ earthly \ --build-arg AWS_ACCESS_KEY_I…
It’s a build tool, I’d be surprised if something like it worked well for non build related tasks. I suspect bazel would be equally verbose (if not even worse or impossible). I think you’re better of using something like taskfile w/ earthly for a really good workflow, it gives you the best of both worlds. (Actually I think I saw this on their slack)
They sell it as a make replacement. Bazel constantly says "you don't need hazel, it is a big tool" and earthly does not. Which is fine.
Either way, I already said earthly is a great tool. This is just my feedback around why it doesnt fit my use case.
I tried using Earthly, great product. Unfortunately, we rejected it at our organization due to how verbose the commands are. I want my users to be able to say `earthly plan-stage` for a terraform repo, and for it to work. But you cannot. You cannot have earthly automatically use environment variables from your env, you have to explicitly list the commands yourself using flags: $ earthly \ --build-arg AWS_ACCESS_KEY_I…
You may want to use secrets like this: earthly \ --secret-file config=/home/user/.aws/config \ +build But yes, Earthly optimizes for reproducibility, so implicitly pulling in ENVs is not something it does.
I tried using Earthly, great product. Unfortunately, we rejected it at our organization due to how verbose the commands are. I want my users to be able to say `earthly plan-stage` for a terraform repo, and for it to work. But you cannot. You cannot have earthly automatically use environment variables from your env, you have to explicitly list the commands yourself using flags: $ earthly \ --build-arg AWS_ACCESS_KEY_I…
> The #1 reason people use Earthly today is to be able to reproduce CI builds locally. Earthly helps create a consistency layer, providing a level of guarantee that the build will run the same on your machine as on your colleagues machine, and as in CI. We call this consistency repeatability (note that this is distinct from reproducibility as full determinism is not guaranteed). > This helps avoid cases where tweaks…
You can see this in action with the Elixir Phoenix framework. They have an earthfile[1] and use github actions[2] to run it for CI.
Even if you don't use Earthly, using a vendor neutral format to describe your build process can help with iteration time.
[1] https://github.com/phoenixframework/phoenix/blob/master/Eart...
[2] https://github.com/phoenixframework/phoenix/actions/runs/146...