HagiCode Release is the automation hub for turning built artifacts into distributable releases, container images, and publish records.
This repository connects version discovery, GitHub Releases, and multi-registry Docker publishing so HagiCode builds can move from generated packages to public delivery.
- Monitor version sources and decide when a release pipeline should run
- Publish application packages to GitHub Releases
- Build and push multi-architecture Docker images
- Synchronize publish results and release metadata across delivery channels
- Ship the streamlined CLI baseline used inside the unified container runtime
nukeBuild/- release automation targets and shared build logic.github/workflows/- CI/CD pipelines for monitoring and publishingdocker_deployment/- container build context, Dockerfiles, and entrypoint scriptsoutput/- generated artifacts during local release workENVIRONMENT_VARIABLES.md- runtime and publishing configuration reference
./build.sh VersionMonitor
./build.sh GitHubRelease --ReleaseVersion "1.2.3"
./build.sh DockerRelease --ReleaseVersion "1.2.3" --DockerPlatform "all"Use repository-specific credentials and registry settings from ENVIRONMENT_VARIABLES.md when preparing a real release.
Automatic publishing now has a single entry point:
./build.sh VersionMonitorstill discovers every unpublished Azure version, but it auto-selects only the newest unpublished version for the current run- GitHub Release automation starts only from
repository_dispatchwith event typeversion-monitor-release - Docker automation starts only from
repository_dispatchwith registry-specific event types (version-monitor-docker-aliyun,version-monitor-docker-azure,version-monitor-docker-dockerhub) - Older unpublished versions are reported as deferred backlog for later scheduled runs or manual handling
Manual reruns stay available, but they are explicit:
github-release-workflow.ymlrequiresworkflow_dispatch.version- Each
docker-build-*.ymlworkflow requiresworkflow_dispatch.versionand keeps optionalplatform/dry_run - Creating or reusing a Git tag no longer auto-starts GitHub Release or Docker workflows
The unified runtime image now builds from a clean debian:bookworm-slim base instead of inheriting the official node image user model. Node.js 24 is installed through an image-managed NVM layout under /usr/local/nvm, while baked CLIs remain installed under /home/hagicode/.npm-global.
Only hagicode is supported as the non-root runtime user. When PUID and PGID are provided, container startup remaps that single user and reconciles ownership for /home/hagicode, its .claude state, and /app.
The unified runtime image bakes only the primary agent CLI baseline:
claudeopencodecodex
openspec remains in the image as the retained workflow tool for spec-driven changes, but it is documented separately from the primary agent CLI baseline so provider scope does not expand again by accident.
Provider CLIs such as copilot, codebuddy, and qodercli now follow the HagiCode UI-managed install path instead of shipping in the container by default. uipro is no longer part of the image because skill management replaces its previous shipped-runtime workflow.
The release image now installs openssh-client and can import a mounted private key during startup when SSH access is explicitly required.
- Set
SSH_PRIVATE_KEY_PATHto a mounted private key file to enable bootstrap - Optionally set
SSH_KNOWN_HOSTS_PATHto import a mountedknown_hostsfile - Optionally set
SSH_STRICT_HOST_KEY_CHECKINGto override the documented default ofaccept-new - Leave
SSH_PRIVATE_KEY_PATHunset to skip SSH bootstrap entirely
At startup the entrypoint copies the mounted key into /home/hagicode/.ssh/imported_key, writes deterministic SSH config at /home/hagicode/.ssh/config, fixes ownership for the hagicode runtime user, and exports GIT_SSH_COMMAND so downstream git and ssh commands use the imported identity.
If SSH_PRIVATE_KEY_PATH is set but the file is missing, unreadable, or not a regular file, container startup fails fast with path-level diagnostics and never prints secret contents.
HagiCode Release takes outputs produced by repositories such as repos/hagicode-core and repos/hagicode-desktop, then publishes them to GitHub Releases, Azure ACR, Aliyun ACR, DockerHub, and related delivery channels.