- integrations
- Bazel
- Reference
- Bazel
- Reference
- Rules and macros
- ocx_project_repo
ocx_project_repo
ocx_project_repo
Section titled “ocx_project_repo”
load("@rules_ocx//ocx:defs.bzl", "ocx_project_repo")
ocx_project_repo(name, allow_unverified, allow_yanked, bins, config, groups, isolated_home,
no_config, ocx, ocx_lock, ocx_toml, patch_snapshot, platform, sigstore_trusted_root)
Provisions the toolchain declared in a workspace ocx.toml/ocx.lock.
Fails when the lockfile is stale or missing (fix with ocx lock). Every
executable the toolchain’s packages declare as their public surface
(ocx inspect --closure) becomes a runnable target //:<name>; a package
shipping no complete binaries metadata falls back to scanning the composed
PATH, which also exposes its private executables — //:env.bzl’s
OCX_SCANNED_PACKAGES names the packages that forced it. The raw
environment is loadable from the same file (OCX_ENV, OCX_HOME).
With bins, provisioning is lazy: nothing is pulled at fetch time, and each
named executable becomes a launcher that re-enters ocx exec — content
materializes on first execution and never becomes a Bazel action input, so
fully remote-cached builds download no tool content at all.
groups scopes both the pull and the composed environment. Omitted, ocx’s
defaults apply: every group is pulled, but only the default [tools] table
is composed into launchers — name groups explicitly (or use the reserved
all) to expose their executables.
platform composes a foreign platform’s environment from the same
ocx.lock: that platform’s leaves are pulled into the store and env.bzl
holds their absolute store paths (sysroots, target libraries, container
image content). Foreign repos expose no runnable launchers — the binaries
do not run on this host.
ATTRIBUTES