ci(harbor): parallel-push docker workflows to harbor.blockcast.net - #43
Merged
Conversation
…utover For docker.yml, docker-agent.yml, docker-mcp-gateway.yml: - Add a second docker/login-action step authenticating to harbor.blockcast.net with the org-level HARBOR_USERNAME / HARBOR_PASSWORD secrets (backed by the pusher-cluster Harbor robot, push+pull all projects, never expires). - Extend metadata-action's images: input to a multi-line list so every tag the meta step emits gets pushed to both registries. Cache (cache-from/cache-to) stays on the Blockcast registry for now — swapping it to Harbor mid-cutover would invalidate the warm buildcache and add full-rebuild time to every PR. Will switch in a follow-up after zot retires. Goal: when zot scales to 0, the cluster (which already pulls from Harbor since today's onprem-k8s cutover commits) keeps working AND new builds keep landing in Harbor. After bake-in, drop the Blockcast-registry login + the first image entry in metadata-action and switch caches to Harbor. No change to push events / triggers / build matrix.
kkroo
added a commit
that referenced
this pull request
May 17, 2026
…push target (#48) Harbor parallel-push (PR #43) has been live since 2026-05-17 07:38Z; the mcp-gateway build at 07:40Z verified end-to-end push to both registries successfully. Now ready for the next cleanup step in the zot retirement plan: drop the zot half of the parallel-push so builds land in Harbor only. This change unblocks the registry.blockcast.net DNS A-record flip from zot's IP (69.25.95.97) to Harbor's IP (69.25.95.125). After this PR merges and a build proves clean, any flat zot references (like buildcache pulls keyed on registry.blockcast.net/...) would resolve to Harbor and 404 on the flat path — so we have to retire them at the source first. Per workflow: - docker.yml (paperclip server image): * removed "Login to Blockcast registry" step * dropped the BLOCKCAST_REGISTRY_HOST entry from metadata-action's images: list * flipped cache-from/cache-to from registry.blockcast.net/paperclip to harbor.blockcast.net/paperclip/paperclip * dropped `vars.BLOCKCAST_REGISTRY_HOST != ''` from the deploy job gate (was used as a sentinel for "CI deploy enabled"; the dedicated `vars.PAPERCLIP_CI_DEPLOY == 'true'` check already covers that) - docker-agent.yml (paperclip-agent image): * removed "Login to Blockcast registry" step * dropped the BLOCKCAST_REGISTRY_HOST entry from images: * cache-from/cache-to were already on Harbor (PR #45) - docker-mcp-gateway.yml (paperclip-mcp-gateway image): * removed "Login to Blockcast registry" step * dropped the BLOCKCAST_REGISTRY_HOST entry from images: * flipped cache-from/cache-to to Harbor * updated stale comment that referenced BLOCKCAST_REGISTRY_PASSWORD Repo variable BLOCKCAST_REGISTRY_HOST and secret BLOCKCAST_REGISTRY_PASSWORD are now unreferenced; can be deleted from repo Settings as a follow-up. Buildcache impact: the first build per image after this lands will be cold (the v6 buildcache tags currently live in zot; Harbor's buildcache-v6 in each project is empty). Subsequent builds will be warm. Acceptable cost for cleanup. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6 tasks
13 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds Harbor as a second push target for paperclip's three image-build workflows during the zot → Harbor cutover bake-in:
docker.yml(paperclip-server)docker-agent.yml(paperclip-agent)docker-mcp-gateway.yml(paperclip-mcp-gateway)Each workflow gains a second
docker/login-actionstep authenticating to harbor.blockcast.net, and metadata-action'simages:becomes a multi-line list so every tag the meta step produces lands in both registries.Why
Cluster pulls already migrated to Harbor today (onprem-k8s commits
c8ede51,48c4233,9edbf0d,0726854). If we don't add a Harbor push, the next builds will only land in zot — which is being retired — and the cluster will drift.Parallel push instead of switch-and-cross-fingers because:
After zot retires
Login to Blockcast registrystep in each workflowimages:(the${{ vars.BLOCKCAST_REGISTRY_HOST }}/...one)cache-from/cache-toto Harbor pathsAuth
HARBOR_USERNAME/HARBOR_PASSWORDare org-level Actions secrets backed by thepusher-clusterHarbor system robot (push+pull all projects, never expires). Set in this morning's session as part of the cluster-side cutover.Test plan
registry.blockcast.net/paperclipandharbor.blockcast.net/paperclip/paperclip🤖 Generated with Claude Code