Noridoc: scripts

Path: @/scripts

Overview

The scripts directory contains build and release automation utilities for the beads project. These scripts handle version management, installation with embedded build info, and release orchestration across multiple distribution channels.

Key scripts include version bumping, installation helpers that inject git information at build time, and release coordination across GitHub, Homebrew, PyPI, and npm.

generate-cli-docs.sh

Generates maintained CLI reference docs from the live Cobra command tree in two stages: bd help --docs-root emits vendor-neutral output (the single-file reference plus a generic per-command tree in uncommitted staging), then tools/docsmint post-processes the staging tree into the committed Mintlify pages and splices the CLI Reference pages array in docs/docs.json.

Usage

# Regenerate checked-in CLI docs using a temporary no-cgo build
./scripts/generate-cli-docs.sh

# Regenerate/check against an existing binary
./scripts/generate-cli-docs.sh ./bd
./scripts/generate-cli-docs.sh --check ./bd

Outputs

• docs/CLI_REFERENCE.md from the live Cobra command tree
• docs/cli-reference/*.md (Mintlify pages) via tools/docsmint
• the CLI Reference pages array in docs/docs.json

scripts/check-cli-docs-drift.sh runs the --check mode in CI and fails when the committed copies are stale relative to the live command tree.

check-doc-freshness.sh

Validates marker-based freshness for reference-shaped docs that are not generated from a single clean source.

Usage

./scripts/check-doc-freshness.sh
make check-docs

The script currently checks the reference docs named in engdocs/DOC_INVENTORY.md: CONFIG.md, SETUP.md, ADO_CONFIG.md, JSON_SCHEMA.md, RECOVERY.md, ERROR_HANDLING.md, LINTING.md, and design/otel/otel-data-model.md. Each doc must be listed in the inventory, include a recent Last reviewed: marker, include a Freshness source: marker, and name source paths or globs that exist in the repository.

Set DOC_FRESHNESS_MAX_AGE_DAYS to a nonnegative decimal integer to override the default 90-day review window. The policy threshold is compared as decimal text, so values larger than Bash's integer range remain valid and cannot become arithmetic expressions or overflow. Set DOC_FRESHNESS_TODAY=YYYY-MM-DD when testing date behaviour. Date validation uses Bash integer arithmetic over the proleptic Gregorian calendar, preserves the script's four-digit YYYY-MM-DD domain from 0001-01-01 through 9999-12-31, and does not require Python or platform-specific date parsing. The native date command is used only to supply today's value when DOC_FRESHNESS_TODAY is unset. Pull requests exercise the real process boundary on Linux, macOS, and Git Bash on Windows.

How it fits into the larger codebase

• Build Integration: The install.sh script is referenced in documentation and release processes as the primary user-facing installation mechanism. It integrates directly with the Go build system to ensure full version information is embedded.

• Version Pipeline: Works alongside the version infrastructure in @/cmd/bd/version.go by extracting and passing git information at build time via ldflags.

• Release Automation: The release.sh and bump-version.sh scripts orchestrate the release process documented in @/RELEASING.md, ensuring version consistency across all components (CLI, plugin, MCP server, npm package).

• CI/CD Integration: Goreleaser (configured in @/.goreleaser.yml) uses the same ldflag patterns established by these scripts, ensuring consistency across all installation methods.

• Multi-Channel Distribution: These scripts ensure that whether a user installs via Homebrew, npm, GitHub releases, or direct go install, they get consistent version reporting with full git information.

Core Implementation

install.sh (GitHub issue #503 fix):

The script simplifies local installation from source while ensuring full version information is available in the resulting binary:

1. Usage (lines 1-6):

   • Can be invoked from source checkout with optional custom install directory
   • ./scripts/install.sh installs to $(go env GOPATH)/bin
   • ./scripts/install.sh /usr/local/bin installs to custom location

2. Git Information Extraction (lines 12-14):

   • Extracts full commit hash via git rev-parse HEAD
   • Extracts branch name via git rev-parse --abbrev-ref HEAD
   • Gracefully handles missing git info (returns empty strings in non-git environments)

3. Build Information Display (lines 16-18):

   • Shows user where installation will occur
   • Displays the 12-character short commit hash
   • Displays the branch name for context

4. Installation with Ldflags (line 20):

   • Calls go install with explicit -ldflags to set main.Commit and main.Branch
   • These ldflags inject values that are then picked up by resolveCommitHash() and resolveBranch() in @/cmd/bd/version.go

5. Post-Install Verification (lines 22-24):

   • Immediately runs bd version to show the user that installation succeeded
   • User sees commit and branch info in the output, confirming full version info is present

Makefile Integration (@/Makefile, lines 37-41):

The Makefile's install target uses identical logic:

• Extracts git info at build time
• Passes to go install via ldflags
• Ensures that standard make install produces binaries with full version info, not just make build

Goreleaser Configuration (@/.goreleaser.yml):

All 5 platform builds (linux-amd64, linux-arm64, darwin-amd64, darwin-arm64, windows-amd64) use goreleaser's built-in git variables:

• -X main.Commit={{.Commit}} uses goreleaser's detected commit
• -X main.Branch={{.Branch}} uses goreleaser's detected branch
• Ensures released binaries have full version info without requiring manual extraction

Version Bumping (bump-version.sh and release.sh):

• Coordinates version updates across multiple files (CLI version, plugin metadata, MCP server, npm package)
• Ensures all distribution channels report consistent version numbers
• Integrates with release process documented in @/RELEASING.md

Things to Know

Why Explicit Ldflags Are Necessary:

• go install does not automatically embed VCS information like go build does (even though Go supports it)
• Without explicit ldflags, binaries lack commit and branch information regardless of installation method
• The Makefile and goreleaser configurations compensate for this limitation

Installation Path Resolution:

• The script uses $(go env GOPATH)/bin as the default installation target
• This respects the user's Go configuration and matches standard Go tooling behavior
• Allows overriding for system-wide installations (e.g., /usr/local/bin)

Git Information Fallbacks:

• The script silently handles missing git info (returns empty strings)
• This allows installation in non-git environments or git-less distributions
• The version command in @/cmd/bd/version.go has its own fallback chain

Testing the Version Pipeline:

• After running ./scripts/install.sh, users should immediately see full version info via bd version
• The text output shows format like: bd version 0.29.0 (dev: main@7e70940)
• JSON output includes both commit and branch fields

Release Coordination:

• The install.sh script is independent of release automation
• Users can run it locally to build from any source branch
• Release scripts (release.sh, update-homebrew.sh) handle orchestration across channels and are documented separately in @/RELEASING.md

Platform Compatibility:

• All scripts use POSIX shell constructs (bash on all platforms)
• Git operations work identically on macOS, Linux, and Windows (with Git for Windows)
• The go install command behaves consistently across all platforms

Security Considerations:

• Scripts use set -e to fail fast on any errors
• Git commands are defensive (using 2>/dev/null to suppress errors)
• No shell injection risks as git values are passed as structured arguments

Created and maintained by Nori.