Publish adversaries

Choose a destination, validate the package, and push a version from your machine or a trusted release workflow.

GitHub Actions

Publish from a protected branch or tag with GitHub OIDC and no stored registry credential.

Depot workflows

Publish on Depot with a Depot-bound OIDC grant and the same push action.

The publishing path

Local and CI publishing perform the same three operations. CI is the recommended path for releases because it makes the source revision and publisher identity auditable.

1. Validate and package
Validate adversary.yaml, install locked dependencies, build the project, and create an OCI package.
2. Authenticate to a project
Developers use doomer login --team. CI should use OIDC or a dedicated publishing service account.
3. Push a version
Push an immutable version to the project namespace. Use a protected branch or tag to control automated releases.

Publish from your machine

Use the CLI for development releases and one-off private packages. Replace the project slug, repository name, and version in this example.

bash

# Validate and package the project
doomer validate .
doomer pack . --name security-reviewer

# Authenticate to the destination project and push a version
doomer login --team your-project-slug
doomer push security-reviewer:0.1.0   registry.doomer.ai/your-project-slug/security-reviewer:0.1.0

There is no separate publish command: publishing is pack followed by push. See Distribution for naming, visibility, signatures, and consumption.

Choose CI authentication

Option	Use it when	Required access
OIDC (recommended)	GitHub Actions or native Depot workflows.	A repository trust grant set to Pull & Publish.
Service account	OIDC is unavailable or another CI system publishes the package.	`registry:pull` and `registry:push`.

Keep review and publishing grants separate. Doomer never issues push credentials to pull-request events.