Also, go already has a very good build sysmtem build-in, and hazel really shines when:
- you have a complex codebase with multi-languages: one can build a tool in one language and use it as tool for a another language.
- you simply have a really large code base - you can work on the path //service1/my/service and your colleague can work on //service2/their/service, and only the path got changed needs to rebuild every time.
It eschews docker, and Dockerfiles and their non-determinism, and builds the layers itself, and uses a python lib [1] to push and pull container images.
In order to ensure reproducibility/determinism, however, Bazel doesn't have an equivalent of the RUN instruction. You have to use other Bazel rules to fetch and produce artefacts and add them to an image, and there aren't always rules for what it is you want to do (I have a spot of bother with installing pip packages, for which there is apparently alpha support).
This is, I think, the thing with Bazel: it has to re-invent everything to ensure this reproducibility and hermetic seal, because it doesn't trust existing build tools to do this, and quite rightly so if this is what you're seeking. But I suspect it's going to be painful doing things outside the mainstream supported stuff.
> It eschews docker, and Dockerfiles and their non-determinism, and builds the layers itself [...] But I suspect it's going to be painful doing things outside the mainstream supported stuff.
This should not matter at all. The OCI specification provides an interoperable image format that doesn't care who built the image or how. Docker still doesn't support the OCI yet[1], but tools exist to do conversions[2]. To shamelessly plug my own projects, you can use umoci[3] as a completely unprivileged user to construct images (without using containers if you don't want to) and the resulting images are still usable with Docker (once you convert them from OCI images). This is how we build the official openSUSE images, and it doesn't affect any user of the images that we chose not to use Docker or Dockerfiles to build them.
> This should not matter at all. The OCI specification provides an interoperable image format that doesn't care who built the image or how
The OCI doesn't, but the build tool does care about how the image was built, because of reproducibility etc. But build tools will be able to leverage the kind of stuff you're doing, rather than doing it themselves (like Bazel does).
- umoci looks pretty cool, this is how things should have been done in the first place.
disclaimer: I am one of the rules_docker contributor :D
You are right about the pain that there is no `RUN` equivalent (yet), and I think someone is working on that.
Regarding producing the docker image itself: given Open Container Initiative[1] and its container image spec[2], it is a good thing that multiple tools can produce exchangeable container images and bazel is one of them with its own reproducible properties.
You can checkout Bazel's docker rule: https://github.com/bazelbuild/rules_docker
Also, go already has a very good build sysmtem build-in, and hazel really shines when: - you have a complex codebase with multi-languages: one can build a tool in one language and use it as tool for a another language. - you simply have a really large code base - you can work on the path //service1/my/service and your colleague can work on //service2/their/service, and only the path got changed needs to rebuild every time.