Earthly

@rrjjvv I appreciate the long comment. This is very helpful. I want to recommend Earthly to others for a containerized local build that can be reused in CI to keep local&CI builds consistent.

• You see things in my shoes. This is something I needed a consulting career to grok.
• Using env vars is OK and lowers bloat for Earthly. I recommend tooling for this such as https://github.com/direnv/direnv (though I'm unsure how to manage this in Windows ps/cmd).

I'll try out the approaches you posted, and post back here on my experience. This looks that it tackles the concerns I have with clients not to share internal info by any means.

I can see where project-level configs (or 'tiered' configs) would be nice (like your use-case of having the project disable uploads on behalf of users), but many settings don't make sense or could result in broken builds (like cache/buildkit settings, which are machine-specific). Note that the config location can be set via environment variable as well, if you weren't aware and if it can help.

If you are willing to assume that Earthly is not subversive/malicious, you can use the absence of that verbiage as your proof:

$ wc foo
0 0 0 foo
$ earthly --config foo github.com/earthly/hello-world+hello
loading config values from "foo"
<snip>
Streaming logs to https://cloud.earthly.dev/builds/ea58417b-f614-4cba-aa5f-ba1b349c8cf8

 Build 🔧
————————————————————————————————————————————————————————————————————————————————

Warning: you are not logged into registry-1.docker.io, you may experience rate-limitting when pulling images
              logbus | Setting organization "" and project ""
<snip>
========================== 🌍 Earthly Build  ✅ SUCCESS ==========================

View logs at https://cloud.earthly.dev/builds/ea58417b-f614-4cba-aa5f-ba1b349c8cf8

That's with an empty config and the default log-sharing.

With my personal config:

$ head -n5 ~/.earthly/config.yml
global:
    disable_analytics: true
    disable_log_sharing: true
    profiler: true
    cache_size_mb: 100000
$ earthly github.com/earthly/hello-world+hello
 Init 🚀
————————————————————————————————————————————————————————————————————————————————

           buildkitd | Found buildkit daemon as docker container (earthly-buildkitd)
           buildkitd | Settings do not match. Restarting buildkit daemon with updated settings...
           buildkitd | ...Done

 Build 🔧
————————————————————————————————————————————————————————————————————————————————

              logbus | Setting organization "rrjjvv" and project ""
<snip>
========================== 🌍 Earthly Build  ✅ SUCCESS ==========================

Note that there is no "Streaming logs" or "View logs" messages. Of course, if you need harder proof, you could read the code, do a packet capture, implement your own firewall blocks, etc. But the Earthly crew are good folks that know what they're doing.

@rrjjvv Thank you! I'm new to Earthly, and your comment is just what I needed. I'm coming from a different containerized build tool (https://batect.dev/).

My concerns are:

• Earthly configuration is per-user rather than per-project (so I need a --config cmd flag per-project, which some developers will forget) -- I'll test this out to see what happens with $PROJECT_GIT_ROOT/.earthly/config.yml
• Default is to share logs -- better would be to use a flag/config to enable (see attached image)

There's a distinction between log uploads/sharing (whether to transmit or not) and stream/non-stream (technical mechanism for transmitting, if/when requested). I believe that changelog entry is only about the latter (as was my bug report); they're going all-in with the streaming mechanism. The decision to actually upload or not should still be controlled via https://docs.earthly.dev/docs/earthly-config#disable_log_sharing (which I use, and would notice fairly quickly if it stopped working).

I noticed this recent change, https://github.com/earthly/earthly/blob/main/CHANGELOG.md#v0813---2024-05-28:

Removed deprecated non-streaming log uploading mechanism; log sharing is now only supported by the streaming-upload mechanism. The hidden --logstream and --logstream-upload flags have been removed.

What is the proper way to disable log streaming? In corporate environments, uploading build logs to a 3rd-party is usually disallowed.