| commit | 9dc4e4e3f22ab101f29ed9d7336cea69a1292f12 | [log] [tgz] |
|---|---|---|
| author | Mark Elliot <123787712+mark-thm@users.noreply.github.com> | Wed Oct 09 10:22:37 2024 -0700 |
| committer | GitHub <noreply@github.com> | Wed Oct 09 10:22:37 2024 -0700 |
| tree | fd3861cefbb9a42a23c44426df646ed96a312085 | |
| parent | 1dfe2efad9200fd396a752c877755a356eed8f91 [diff] |
Run our own test matrix (#55)
An ergonomic approach to defining a single tool target that resolves to a matching os and CPU architecture variant of the tool.
For a quickstart, see the module example or workspace example.
Define a lockfile that references the tools to load:
{ "$schema": "https://raw.githubusercontent.com/theoremlp/rules_multitool/main/lockfile.schema.json", "tool-name": { "binaries": [ { "kind": "file", "url": "https://...", "sha256": "sha256 of the file", "os": "linux|macos|windows", "cpu": "x86_64|arm64" } ] } }
The lockfile supports the following binary kinds:
file: the URL refers to a file to download
sha256: the sha256 of the downloaded fileheaders: (optional) a string dictionary of headers to pass to the downloaderauth_patterns: (optional) a string dictionary for use with .netrc files as in https://bazel.build/rules/lib/repo/http#http_file-auth_patternsarchive: the URL referes to an archive to download, specify additional options:
file: executable file within the archivesha256: the sha256 of the downloaded archivetype: (optional) the kind of archive, as in https://bazel.build/rules/lib/repo/http#http_archive-typeheaders: (optional) a string dictionary of headers to pass to the downloaderauth_patterns: (optional) a string dictionary for use with .netrc files as in https://bazel.build/rules/lib/repo/http#http_archive-auth_patternspkg: the URL refers to a MacOS pkg archive to download, specify additional options:
file: executable file within the archivesha256: the sha256 of the downloaded pkg archiveheaders: (optional) a string dictionary of headers to pass to the downloaderauth_patterns: (optional) a string dictionary for use with .netrc files as in https://bazel.build/rules/lib/repo/http#http_archive-auth_patternsOnce your lockfile is defined, load the ruleset in your MODULE.bazel and create a hub that refers to your lockfile:
bazel_dep(name = "rules_multitool", version = "0.0.0") multitool = use_extension("@rules_multitool//multitool:extension.bzl", "multitool") multitool.hub(lockfile = "//:multitool.lock.json") use_repo(multitool, "multitool")
Tools may then be accessed using @multitool//tools/tool-name.
Instructions for using with WORKSPACE may be found in release notes.
When running @multitool//tools/tool-name, Bazel will execute the tool at the root of the runfiles tree due to https://github.com/bazelbuild/bazel/issues/3325.
To run a tool in the current working directory, use the convenience target @multitool//tools/tool-name:cwd.
A common pattern we recommend to further simplify invoking tools for repository users it to:
tools/ directorytools/_run_multitool.sh with the following code:#!/usr/bin/env bash bazel run "@multitool//tools/$( basename $0 ):cwd" -- "$@"
tools/tool-name to tools/_run_multitool.shWe provide a companion CLI multitool to help manage multitool lockfiles. The CLI supports basic updating of artifacts that come from GitHub releases, and may be extended in the future to support other common release channels.
See our docs on configuring a GitHub Action to check for updates and open PRs periodically.