ci: publish container images from releases - #30
Merged
Conversation
16 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
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
Publish prebuilt backend and frontend images through GitHub Actions so deployments normally pull a matched image pair instead of compiling TokenHub on the target host. The frontend now reads its backend API URL at server runtime, allowing one immutable frontend image to be configured after publication.
The publication workflow intentionally does not run for pull requests or merges to
main. It runs for published GitHub Releases or an explicit manualedge/manual-*publication.Related Issue
N/A
Changes
linux/amd64andlinux/arm64backend/frontend images, publishes provenance attestations, and promotes final tags only after both staging images succeed.latestand release tags, serialize publication runs, and reuse per-image GitHub Actions caches.TOKENHUB_API_BASE_URLat server runtime. KeepNEXT_PUBLIC_API_BASE_URLas a documented one-cycle compatibility fallback.ghcr.io/astaxie/tokenhub-{backend,frontend}tags. Default deployments use the model catalog embedded in the backend image;--model-catalogprovides an explicit override.deploy/install.shto pull published images by default, support explicit local builds, and fall back to a local build only when the defaultlatesttag is temporarily unavailable. Explicit version tags never silently fall back.Type of Change
Verification
gofmton changed Go files,go test ./..., andgo vet ./...npm run typecheckandnpm run buildVerification details:
go test ./...andgo vet ./...passed frombackend/../frontend/node_modules/.bin/tsc --noEmitandnpm run buildpassed.npm run typecheckentry point remains blocked by the existing missingfrontend/scripts/check-source-lines.mjsfile on the base branch; direct TypeScript validation passed.bash -n deploy/install.sh deploy/install_test.sh start.shand./deploy/install_test.shpassed.docker compose ... configpassed for SQLite, bundled PostgreSQL, remote PostgreSQL, the legacy API URL fallback, and the custom model catalog override.actionlintv1.7.7 andgit diff --checkpassed.workflow_dispatchrun using the production workflow: https://github.com/legendtkl/TokenHub/actions/runs/30003996190ghcr.io/legendtkl/tokenhub-backend:manual-e2e-dispatch-20260723andghcr.io/legendtkl/tokenhub-frontend:manual-e2e-dispatch-20260723.linux/amd64andlinux/arm64; both attestations passgh attestation verify.linux/arm64containers started successfully, the backend/readyzendpoint returned healthy, and the frontend rendered the runtime API URL.astaxiepackage visibility and repository-level package settings.Compatibility, Security, and Operations
/v1API impact: None.GITHUB_TOKEN, grants write permissions only to build/promotion jobs, pins third-party Actions to commit SHAs, and publishes provenance attestations. No registry credentials are added to the repository.TOKENHUB_IMAGE_TAGand runtimeTOKENHUB_API_BASE_URL. ExistingNEXT_PUBLIC_API_BASE_URLdeployments retain a compatibility fallback. Default deployments now use the model catalog embedded in the selected backend image../deploy/install.sh --buildremains available for source builds, and deployments can roll back by selecting an earlier matching image tag.Checklist
.envfiles, databases, backups, or runtime logs are included.start.sh, and deployment documentation where applicable.data/model-catalog.yamlremains tracked and catalog changes were reviewed where applicable.git diff --checkpasses.