Scope: everything under tools/.
- Prefer
bashfor small repo-local wrappers, CI entrypoints, and scripts that mostly orchestrate existing CLI tools. - Prefer
Gofor non-trivial tooling: structured parsing, manifest scanning, larger file transforms, concurrency, or logic that benefits from unit tests and a compiled binary. - Avoid adding new Python-based repo tooling when
bashorGois a reasonable fit. Some CI environments in this repo do not guarantee Python. - If Python is still required for a one-off command, use
python3, notpython.
- Put general executable wrapper scripts in
tools/scripts/. - Put CI-focused entrypoint scripts in
tools/ci/. - Put larger Go tools in their own directory under
tools/, for exampletools/collect-dependencies/ortools/generate-subproject-ci/. - If a Go tool needs a stable repo entrypoint for CI or docs, add a thin wrapper in
tools/ci/ortools/scripts/as appropriate, or document the exactgo runorgo build -Ccommand.
- Use hyphens, not underscores, for filenames under
tools/, especially undertools/scripts/. - Examples:
collect-notices,check-license-headers,check-dependency-licenses,test-collect-notices. - Keep test entrypoints aligned with the tool name, for example
test-<tool-name>.
- Keep tools easy to run in CI and local development. Prefer standard library code and common Unix tools over extra dependencies.
- For bash scripts, prefer
#!/usr/bin/env bashandset -euo pipefailunless there is a clear reason not to. - Keep user-facing output concise and actionable. Error messages should say what failed and how to fix it when possible.
- When replacing a tool or changing its entrypoint, update callers, CI jobs, and docs in the same change.
- Add or update focused tests when changing tool behavior.
- For bash tools, prefer shell-based tests under
tools/scripts/test/. - For Go tools, prefer
_test.gounit tests next to the implementation.