[jpgvm]

The trick to Docker (well OCI) images is never under any circumstance use `docker build` or anything based on it. Dockerfile is your enemy.

Use tools like Bazel + rules_oci or Gradle + jib and never spend time thinking about image builds taking time at all.

[Arbortheus]

Please no! Do not use Bazel unless you have a platform team with multiple people who know how to use it - e.g. large Google-like teams.

We had “the Bazel guy” in our mid-sized company that Bazelified so many build processes, then left.

It has been an absolute nightmare to maintain because no normal person has any experience with this tooling. It’s very esoteric. People in our company have reluctantly had to pick up Bazel tech debt tasks, like how the rules_docker package got randomly deprecated and replaced with rules_oci with a different API, which meant we could no longer update our Golang services to new versions of Go.

In the process we’ve broken CI, builds on Mac, had production outages, and all kinds of peculiarities and rollbacks needed that have been introduced because of an over-engineered esoteric build system that no one really cares about or wanted.

[jpgvm]

Bazel isn't for everyone which is why I suggested using any similar tool, jib, Nix, etc. Just not Dockerfile (or if you are going to use Dockerfile only use ADD).

Also just because you don't have experience with something doesn't make it a bad choice. I would recommending understanding it first, why your coworker chose it and how other tools would actually do in the same role, grass is often greener on the other side until you get there.

Personally I went through a bit of an adventure with Bazel. My first exposure to it was similar to yours, was used in a place I didn't understand for reasons I didn't understand, broke in ways I didn't understand and (regretfully) didn't want to spend time understanding.

The reality was once I sat down to use it properly and understood the concepts a lot of things made sense and a whole bunch of very very difficult things became tractable.

That last bit is super important. Bazel raises the baseline effort to do something with the build system, which annoys people that don't want to invest time in understanding a build system. However it drastically reduces the complexity of extremely difficult things like fully byte for byte reproducible builds, extremely fast incremental builds and massive build step parallelization through remote build execution.

[jonathanlydall]

Lack of experience is a perfectly valid and often very rationale reason for something being a bad choice, especially when considering upskilling costs and possible challenges in finding new hires proficient in the chosen technology.

The new technology needs to be sufficiently better than the existing to justify the investment or ongoing additional cost, and not just “has more features”, it should be solving problems which may otherwise not be reasonably solvable.

In a past job we had an incident where a dev had unilaterally decided to develop parts of a .NET project in F#, when the contract was for a C# project to be ultimately handed over to the client.

This was a run of mill back-end API, there were no interesting requirements that could possibly justify saddling the client with a need to hire for a relatively niche language.

The dev in question had this general view that F# was an underrated language and technically better than C# and if other devs would just give it a chance, they’d see for themselves.

What they totally ignored is that hiring C# devs is super easy here, F# though, not so much.

[humanrebar]

If you're saying to use a proper dependency management system (package manager or monorepo build system) and keep Docker to mostly dumb installs, I agree.

Though I also think Nix and Bazel are typically not the right starting points for most projects. If you're not committed to having at least four experts on those complex tools in perpetuity, find something simpler.

To be clear, inventing your own, better system is typically as bad. Language specific ecosystems can be too, but it's often hard to avoid both Maven and gradle if you're a Java shop, for instance.

[jpgvm]

Yeah it's a conundrum. The easiest time to adopt something like Bazel/Buck/etc is at the start. However that is when tools like that provide the least value which given their additional friction isn't a good trade-off.

I recently started a side project and decided to do the whole thing using Gradle instead of Bazel. Essentially committing to writing absolutely everything in Kotlin instead of going for a multi-language setup with a more complex build tool. However Kotlin is a bit special in that regard because with multi-platform you can build for server/desktop/mobile/web all in one language with one build system.

[baobun]

> or if you are going to use Dockerfile only use ADD

So we should do

    ADD https://example.com/fetch-and-install.sh
    RUN sudo fetch-and-install.sh

instead of

    COPY fetch-and-install.sh .
    RUN sudo fetch-and-install.sh

[dindresto]

+1 to this, migrating our build setup to Nix + nix2container decreased our pipeline duration for incremental changes by a lot, thanks to Nix's granular caching abilities.

[jpgvm]

Yeah I really need to actually sit down and learn Nix, seems like it can solve this in a more general way for cases where the thing you want to run is packaged for Nix already.