Skip to content

ocx-mirror

Upstream projects publish their releases as loose archives on GitHub Releases or ad-hoc download pages. Consuming them from CI means hand-maintaining URL matrices per platform, re-checking for new versions, and hoping nobody published a broken binary.

ocx-mirror automates that. You describe one tool in a YAML spec — where releases come from, which asset belongs to which platform, where to publish — and ocx-mirror mirrors every matching upstream version into an OCI registry as an OCX package. Consumers then install the tool with ocx add, on any platform, from your registry.

What it does

  • Sources — GitHub Releases or URL indexes (remote JSON, inline versions, or a generator command).
  • YAML spec — one mirror.yml per tool: source, per-platform asset regexes, target registry, version bounds.
  • Two-phase pipeline — prepare (download, verify, bundle) runs concurrently; push runs sequentially by version so cascade tags (X.Y.Z → X.Y → X → latest) always land in semver order.
  • Generated CI pipelines — pipeline generate ci renders complete GitHub Actions workflows that discover new versions on a schedule, smoke-test every (version, platform) pair before publishing, and report results to Discord.

Beyond one tool at a time

Two sibling namespaces serve corporate deployments that cannot reach the public internet:

  • registry sync copies whole upstream OCX indexes — every package they list — into a registry you control, and writes the index tree describing your copy.
  • dist sync mirrors the bootstrap layer: ocx's own release archives and the dist.json manifest naming them, into a generic HTTP store. It is what lets a machine with no route to github.com install ocx in the first place.

Install

ocx-mirror is itself distributed as an OCX package:

ocx --global add ocx.sh/ocx/mirror

Where to go next