OpenClaw EnterpriseDOCSGitHub

OCC CLI publication flow

Overview

The manual CLI release workflow builds versioned occ binaries for macOS and Linux, verifies their platform and checksum identities, and publishes the exact assets in a GitHub Release. The flow ends when the release is published. It does not install OCC or publish the Helm chart and container images.

Entry Points

Flow

graph TD
  A["Select main source and successful CI"] --> B["Validate source, CI and OCE version"]
  B --> C["Build four versioned Go binaries"]
  C --> D["Check platform metadata, native command and SHA-256"]
  D --> E["Retain exact assets in the workflow run"]
  E --> F["Revalidate source, CI and protected environment"]
  F --> G["Create or verify source tag and draft release"]
  G --> H["Upload missing assets and compare downloads"]
  H --> I["Publish the verified draft"]

Execution Trace

1. Bind the source to a tested OCE version

scripts/ci/cli-release.ts:validate requires a manual dispatch from this repository's main, a full source SHA matching the selected workflow source commit, and a successful CI Required job from the exact main-push CI run. The root package version and chart version and appVersion must agree. These checks do not prove that the chart or images have been published; the operator coordinates those separate releases from the same source.

2. Prepare the binaries before write access

scripts/ci/cli-release.ts:packageCli resolves its output directory to an absolute path, including when the caller supplies .. Native verification executes that file without searching PATH. It builds with CGO_ENABLED=0 for Darwin and Linux on amd64 and arm64 using pinned Go 1.27.3. The build embeds v<version> in the CLI, checks the source commit and Go platform metadata, runs --version and --help on the runner-native binary, and writes SHA256SUMS. The prepare job has read-only repository permission and retains its output as one workflow artifact. The publication job consumes that artifact without rebuilding it. The prepare job passes its artifact name to the publication job, so a failed-job rerun can use the original build artifact.

3. Publish only the verified bytes

scripts/ci/cli-release.ts:publish rechecks source, CI, the protected container-publish environment, and each local checksum. It creates a lightweight version tag only when none exists; a matching tag is required on a retry. It finds an existing draft through the authenticated release list, creates one if absent, and uploads only missing assets, downloads every asset, and compares each byte with the prepared artifact before publishing the draft. An existing published release is not modified. A partial failure leaves a draft and tag for inspection and a matching retry.

This assumes trusted release administrators do not change the tag or draft during publication. The workflow concurrency group serializes participating jobs but cannot exclude independent GitHub writers. A competing write between the asset checks and draft publication could invalidate their binding. The published release is the user-facing artifact; the separate chart and image receipt owns deployment provenance.

Debugging and Verification

Search documentation