These rules may not be suitable for you, they are not setup/designed to cover a huge set of use cases. Pull requests to add new features, especially those well factored to keep the core small will be accepted. For a far more broad set of support, and if in doubt, generally use: https://github.com/bazelbuild/rules_docker
Note: This repository requires Bazel 6.0+ with Bzlmod enabled.
Add the following to your MODULE.bazel file:
bazel_dep(name = "rules_minidock", version = "0.1.0")
# Use git_override since rules_minidock is not published to the Bazel registry
git_override(
module_name = "rules_minidock",
remote = "https://github.com/bazeltools/rules_minidock",
commit = "<git_commit>",
)To update the multitool binaries (merge-app, pusher-app, puller-app) to a new version:
./minidock/remote_tools/update_multitool_remote_tools.shThis updates minidock/remote_tools/multitool.lock.json with the latest tool versions.
Less dependencies, there is no need of any other support java/go/rust to use these rules. All tools are pre-built in the rules_minidock_tools repo, and are supplied for a few platforms. Generally if these tools don't meet your needs, we aim to have these rules setup so that it should be easy and reasonable to swap out these tools for others as you see fit. That is, primary tooling covers:
- Fetching metadata about a given upstream tag. We expect to download and expose information from the OCI distribution spec as the starting point
- Producing compatible compressed gzip data (a python file, using from rules_docker here).
- Taking the outputs from the structs/providers built up during the build and emitting the OCI manifest, config, and layer information.
- An uploader which will take the information composed in (3) and upload this to your registry. The implementation today does not support authentication, non-critical features. It is built to aim to copy the layer blobs from (1) if necessary from the source repo to the destination repo.
If you have custom needs, or desires to use internal technology for your company, replacing the tools for (1) and (4) would allow you to drop in anything else here. If some off the shelf application can meet the needs of (4) to limit data transfer then we should move to it instead.
- Integration with bazel remote cache technologies so large local layers could be built on a remote server and pushed into the docker registry from there
- Delay/do not fetch any metadata in (1), use this tool (or a user supplied replacement) to run (1), (3) and (4) all as part of the run operation. This will stop the build validating the external state/accuracy of source digests (could change anyway?), but it would mean tools could be built/delivered without repository rules. < 81E2 li>Support local docker daemon building + images into.
- Right now platform + architecture is all limited to linux/amd64. For simplicity and our use case, would accept PR's if anyone wants to increase the coverage here.
- Replace build_tar.py with a pre-built app to not rely on python.
- improve stamping support
While a lot of the code here has been rewritten for this narrower use case, some code is taken from (Apache Licenced) rules_docker. The API's are in no small part inspired from that project also.
The dependency configuration in these rules to align containers vs bazel, has the caveat that overrides occur in the depset order. So the depset of actions will be linearized, and then applied as a stack. With the special carve out that we will only apply one base configuration, so we find that first, and apply everything ontop of it.
Fetches metadata about containers from a remote registry. Declare external containers in your MODULE.bazel:
external_containers = use_extension("@rules_minidock//minidock:external_container_repo.bzl", "external_container_repo")
external_containers.container(
name = "base_image",
digest = "sha256:abcd1234567890abcdef1234567890abcdef1234567890abcdef1234567890ab",
registry = "docker.io",
repository = "library/alpine",
)
external_containers.container(
name = "app_base",
digest = "sha256:1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcdef",
registry = "gcr.io",
repository = "my-project/base-image",
)
use_repo(
external_containers,
"base_image",
"app_base",
)These hooks to allow setting of configuration options such as CMD, ENTRYPOINT and ENV
This rule allows you to specify data which should be available as a layer. It allows including tar's, setting permissions on files, and placing files in particular locations in the resulting data.
This allows you to compose several container_config, and container_data and optionally one external_container_repo. These can be then composed by further container_compose calls as necessary.
This is the rule to exit bazel again. It takes a container_compose as an input to describe the computation. It will emit at build time the oci container manfiest, and configuration. If it is invoked with bazel run , it will upload it to to the specified registry.