mirror of
https://github.com/hanzoai/replicate.git
synced 2026-10-30 18:23:20 +00:00
zeekayandHanzo Dev
784c988540
This repo called hanzoai/.github's docker-build.yml, which pushes to ghcr and stops. hanzoai/ci's build.yml makes the same push and then copies the tag set to oci.hanzo.ai server-side, so the image exists at both addresses and the fleet can pull from ours. ghcr is not retired — it stays as the public mirror, the same arrangement source already has. Two things about this repo that the next migration should not copy blindly: VERSION says 0.5.13 while ghcr has published through 0.9.10, which is the tag production runs. It is left alone on purpose. imgver takes the max of the declared version and the registry floor, so it reads 0.9.10 and publishes 0.9.11 — the series continues and the stale file changes nothing. Raising VERSION would claim a release this repo never cut; setting it to match would type a number that is already derived. The tag SHAPE changes: docker-build.yml published `v0.9.10`, imgver publishes bare `0.9.11`. That is safe here because every consumer names a tag explicitly — replicate is a sidecar in chat, dataroom and hanzo-app-base, and each moves when its pin moves, not before. Nothing resolves a floating tag. .github/workflows' two docker-build callers are deleted rather than left behind: adding .hanzo/workflows makes the whole of .github/workflows dark on git.hanzo.ai (Gitea reads the first of those directories present), so leaving them would leave two files that read as live and are not. It also gains a gate it did not have — the old lane ran none. `go build ./...` and `go vet ./...` both pass on this tree today, which is what makes adding them safe rather than a wager. Co-authored-by: Hanzo Dev <[email protected]>
37 lines
1.5 KiB
YAML
37 lines
1.5 KiB
YAML
# Hanzo Replicate — the one file that says how this repo builds, gates and ships.
|
|
#
|
|
# It replaces callers of hanzoai/.github's docker-build.yml, which push to ghcr
|
|
# and stop there. hanzoai/ci's build.yml makes the same push and then copies the
|
|
# tag set to oci.hanzo.ai — server-side, no rebuild — so the image exists at both
|
|
# addresses. ghcr stays as the public mirror; what changes is that ours gets a
|
|
# copy at all.
|
|
#
|
|
# THE VERSION FILE BELOW IS STALE AND DELIBERATELY LEFT ALONE. VERSION says
|
|
# 0.5.13 while ghcr.io/hanzoai/replicate has published through 0.9.10 — the tag
|
|
# production runs. imgver takes the MAX of the declared version and the registry
|
|
# floor, so it reads 0.9.10 and publishes 0.9.11; the series continues and the
|
|
# stale file changes nothing. Editing VERSION upward would be a version this repo
|
|
# never released, and editing it to match would be typing a number that is
|
|
# already derived. The published image has been the source of truth here for a
|
|
# while, and this makes that explicit rather than pretending the file leads.
|
|
#
|
|
# Note the tag SHAPE changes: docker-build.yml published `v0.9.10`, imgver
|
|
# publishes bare `0.9.11`. Every pin names a tag explicitly, so nothing resolves
|
|
# by accident — the three deployments that carry this as a sidecar move when
|
|
# their pin moves, not before.
|
|
|
|
test:
|
|
- name: build-and-vet
|
|
run: |
|
|
set -e
|
|
go build ./...
|
|
go vet ./...
|
|
|
|
images:
|
|
- name: replicate
|
|
context: .
|
|
dockerfile: Dockerfile
|
|
repo: ghcr.io/hanzoai/replicate
|
|
platforms:
|
|
- linux/amd64
|