Documentation

Publishing

The registry accepts only artifacts that carry their own provenance — so publishing is CLI-only, never an upload form. Gemara artifacts go through grcli; evaluators through pvtr.

Publishing artifacts (grcli)

After signing in, validate the bundle locally against a checkout of the Gemara spec, then publish it:

$grcli validate -f <bundle>.yaml --spec <path-to-gemara-checkout>
$grcli publish <bundle>.yaml

grcli reads the version from metadata.version, signs and publishes the bundle, and the hub indexes it. You may publish if either you hold the write:<Type> role for that artifact type, or you are a member of the publishing organization (organization membership grants publish authority to that namespace). A member of finos-ccc can publish controls under finos-ccc either way.

Versions are immutable: re-publishing the same body at the same version is idempotent, but a different body at an existing version is rejected — bump metadata.version per release. Every artifact page links to a per-artifact publish helper with the exact commands.

Publishing evaluators (pvtr)

Evaluator plugins are published with Privateer's pvtr publish. Publishing is authorized by namespace ownership — you can publish to <namespace>/plugins/<id> only for a namespace you own — and the plugin index must be cosign-signed; the hub verifies that signature at ingest.

Trusted publishing from CI

From GitHub Actions, no sign-in is needed — the workflow's own OIDC token does secret-less trusted publishing, once an organization admin has registered the repository as a trusted publisher. This is the recommended path for both artifacts and evaluators.

📖 The full publish contract for evaluators (index shape, signing, the /sync step) lives with Privateer at privateerproj.com.