mirror of
https://github.com/hanzoai/datastore.git
synced 2026-09-26 13:55:07 +00:00
zeekay
50f29ddfaa
The build never reached the C++ compile: imgver runs before docker buildx, and it exits non-zero rather than let a build fall back to sha-<short>. datastore declared a version nowhere imgver looks — no package.json, no Cargo.toml, no VERSION, and the root pyproject.toml is pylint configuration with no `version =` key — so it died with "no version for ghcr.io/hanzoai/datastore" about a minute in. Run #2 did not show this because it ran an older build.yml that never called imgver; the ci v1 that main resolves to now does. 26.7.1 is read off the tree, not chosen: cmake/autogenerated_versions.txt carries VERSION_MAJOR 26, VERSION_MINOR 7, VERSION_PATCH 1. Upstream's VERSION_STRING is the four-component 26.7.1.1 and imgver's semver is three, hence 26.7.1. Declaring it is safe against an unknown registry floor, which matters because the floor could not be read from here (the available credential lacks read:packages). imgver publishes max(declared, published): verified against the real script at three floors — none -> 26.7.1, 26.7.1 -> 26.7.2, 26.7.9 -> 26.7.10. The series cannot be walked backwards by naming a lower number, and no tag can ever cover two digests. Same shape and same reason as hanzoai/postgres, which declares version: 18.0.0.
67 lines
3.6 KiB
YAML
67 lines
3.6 KiB
YAML
# Canonical CI config for hanzoai/datastore — read by the hanzoai/ci reusable
|
|
# (.hanzo/workflows/build.yml) and by platform.hanzo.ai.
|
|
#
|
|
# One image, built from source by the repo-root Dockerfile. See that file for why
|
|
# source and not docker/server/Dockerfile (short version: the .deb path points at
|
|
# packages.hanzo.ai, an apt repo that does not exist).
|
|
|
|
# The version this image publishes, and it has to be stated here rather than
|
|
# derived: imgver reads a repo's own manifest — package.json / Cargo.toml /
|
|
# VERSION / pyproject.toml — and nothing in this tree carries a number. The root
|
|
# pyproject.toml is pylint configuration with no `version =` key, so imgver finds
|
|
# nothing and exits non-zero ("no version for ghcr.io/hanzoai/datastore") BEFORE
|
|
# docker buildx is ever invoked. hanzoai/postgres declares its 18.0.0 for the
|
|
# same reason.
|
|
#
|
|
# The number is not invented. cmake/autogenerated_versions.txt says VERSION_MAJOR
|
|
# 26, VERSION_MINOR 7, VERSION_PATCH 1 — this tree IS 26.7.1. (Upstream's
|
|
# VERSION_STRING is the four-component 26.7.1.1; imgver takes three.) Naming it
|
|
# cannot walk the series backwards: imgver publishes max(declared, published),
|
|
# so a higher tag already at the registry still wins and gets its next patch.
|
|
version: 26.7.1
|
|
|
|
images:
|
|
- name: datastore
|
|
context: .
|
|
dockerfile: Dockerfile
|
|
repo: ghcr.io/hanzoai/datastore
|
|
# Explicit even though it is the reusable's default: DOKS has no arm64 nodes,
|
|
# so arm64 would be a QEMU-emulated C++ build — days, not hours — for a node
|
|
# pool that cannot schedule it. Revisit only when DO ships arm64 droplets.
|
|
platforms: [linux/amd64]
|
|
|
|
# NO `test:` block, and that is a deliberate statement rather than an omission.
|
|
#
|
|
# `test:` entries run directly ON the runner, before the artifact exists — but
|
|
# everything worth asserting about this repo is a property of a binary that takes
|
|
# hours to produce. The gate therefore lives inside the Dockerfile, as the last
|
|
# layer: it runs `SELECT version()` and reads system.build_options through the
|
|
# binary it just linked, so an image that cannot answer a query is never pushed.
|
|
# That is a real gate on the real artifact, and it fails the build.
|
|
#
|
|
# The upstream suites (ci/, tests/) are a separate machine — stateless/integration
|
|
# runs that need a server, a keeper and fixtures. They belong in their own
|
|
# workflow against an already-published tag, not in the path that produces it.
|
|
|
|
# NO `deploy:` block, deliberately and importantly.
|
|
#
|
|
# The live instance is StatefulSet `datastore` in namespace `hanzo`, running
|
|
# 26.2.3.2 with ~155 days of telemetry, and 26.7 is NOT a drop-in for it. Two
|
|
# independent one-way doors:
|
|
#
|
|
# 1. Data path. Live resolves `path` to /var/lib/hanzo-datastore/ and mounts
|
|
# both its PVC and its ConfigMaps there. This tree compiles in
|
|
# /var/lib/datastore/ instead, and no image bakes an overlay that says
|
|
# otherwise — so an image-only swap misses the volume AND every config
|
|
# mount, initializes an empty database on the container's ephemeral layer,
|
|
# and passes its /ping probes while doing it. Green, and silently empty.
|
|
# 2. Part format. Crossing 26.3 makes new parts unreadable by older versions,
|
|
# so the rollback is a volume snapshot, not a tag revert.
|
|
#
|
|
# An automated rollout is exactly the wrong shape for that. It has to be a
|
|
# reviewed change that moves the image and the mount paths in one commit, behind
|
|
# a snapshot, asserting `system.server_settings.path` afterwards.
|
|
#
|
|
# So this pipeline BUILDS and PUBLISHES only. Rollout stays a reviewed tag pin in
|
|
# hanzoai/universe, the same rule cloud, ci and git follow.
|