Makefile entrypoints¶

The platform build, test, audit, and publishing entrypoints live in the root Makefile. The workflows call these targets instead of repeating logic in YAML. Workflow triggers and gates are in Continuous integration and Releases.

Makefile entrypoints used by workflows¶

The workflows intentionally reuse a small set of Makefile targets:

make init-workspace
make hub-assets
make test
make fuzz-go [FUZZTIME=<duration>]
make dependency-audit
make dependency-audit-python
make dependency-audit-go
make dependency-audit-npm
make dependency-audit-fix
make dependency-update-check [-python|-go|-npm]
make dependency-update [-python|-go|-npm]
make check-lockstep-version
make print-version
make publish-images IMAGE_TAG=<tag>
make publish-helm CHART_VERSION=<semver> [IMAGE_TAG=<tag>]
make publish IMAGE_TAG=<tag> [CHART_VERSION=<semver>]
make publish-develop
make release
make release-notes
make build-docs
make publish-docs
make check-docs-nav

Their roles are:

Helm chart versions must be SemVer. The develop image tag is not a valid chart version, thus the develop chart uses the <VERSION>-develop pre-release version.

Makefile variables¶

These variables tune the targets. The workflow jobs set some of them; the rest are local overrides.

Dependency updates¶

Dependabot updates the uv, Go module, npm, GitHub Actions, and Docker ecosystems, and Renovate updates site/proxy.Dockerfile. Both run weekly with a seven-day cooldown. The dependency-update targets cover the same ground on demand, for example before a release. They use the same cooldown, so they do not select a release that Dependabot would still hold back.

utilities/release/dependency_updates.py implements both actions for one ecosystem:

uv run --no-project --python 3.13 python utilities/release/dependency_updates.py {check|update} {python|go|npm}

The check action runs the tool in report mode and writes nothing. The update action runs the same tool again to apply what the report lists, so it applies no surprise. Both actions print the release cutoff they used.

A Python dependency lives in two places. Each member pyproject.toml file pins its direct dependencies with ==, and uv lock --upgrade cannot move such a pin. The tool therefore reads every pin, asks uv pip compile for the newest release that the cooldown allows, rewrites the pin in place with uv add --frozen, and then re-locks uv.lock. The final plain uv lock removes the cutoff that a bounded lock records in uv.lock; it changes no version, so a later uv sync leaves the file alone. A pin that already holds the newest allowed release is not rewritten, and a requirement with a range keeps its range. uv add needs a package name to select a manifest, so the tool lists a pin of the workspace file for a manual change.

An update covers dependency files only. It does not run the tests, the audits, or the license checks, and it does not open a pull request. Docker image pins, the declared Go go and toolchain directives, and the pinned audit tool versions are out of scope. The Go part covers the modules that go.mod requires. go list -m -u all also reports a module that only the module graph needs, with no line in go.mod; an update would add such a line, and go mod tidy would remove it again, so the tool leaves that module to the one that asks for it. Review the diff, run make test and make dependency-audit, then commit the result on a branch.

Release-note extraction (make release-notes → utilities/release/changelog-notes.sh) prints the CHANGELOG.md section for the version in VERSION. Pass a version argument to select another section, and set CHANGELOG_FILE to read another changelog:

./utilities/release/changelog-notes.sh 2.6.0
CHANGELOG_FILE=/tmp/CHANGELOG.md ./utilities/release/changelog-notes.sh