Skip to content

HagiCode-org/releases

Repository files navigation

HagiCode Release

简体中文

HagiCode Release is the automation hub for turning built artifacts into distributable releases, container images, and publish records.

Product overview

This repository connects version discovery, GitHub Releases, and multi-registry Docker publishing so HagiCode builds can move from generated packages to public delivery.

What this repository handles

  • 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

Main areas

  • nukeBuild/ - release automation targets and shared build logic
  • .github/workflows/ - CI/CD pipelines for monitoring and publishing
  • docker_deployment/ - container build context, Dockerfiles, and entrypoint scripts
  • output/ - generated artifacts during local release work
  • ENVIRONMENT_VARIABLES.md - runtime and publishing configuration reference

Common release commands

./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.

Trigger boundaries

Automatic publishing now has a single entry point:

  • ./build.sh VersionMonitor still 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_dispatch with event type version-monitor-release
  • Docker automation starts only from repository_dispatch with 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.yml requires workflow_dispatch.version
  • Each docker-build-*.yml workflow requires workflow_dispatch.version and keeps optional platform / dry_run
  • Creating or reusing a Git tag no longer auto-starts GitHub Release or Docker workflows

Container CLI contract

The unified runtime image bakes only the core release CLI baseline:

  • claude
  • openspec
  • opencode
  • codex

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.

Ecosystem role

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.

About

Release automation hub for packaging HagiCode artifacts, publishing GitHub releases, and shipping multi-architecture container images.

Topics

Resources

Stars

Watchers

Forks

Contributors