Use Ravenstash in CI/CD

CI jobs keep a durable automation token in RVS_TOKEN so rvs can authenticate. That token is a controller credential, not the credential shown to a package manager. Before native registry access, exchange it for a short-lived token scoped to the target repository, package format, and required access.

Choose the token owner

Choose a token targeting the account that owns the package repository:

• Use a personal token only for personal repositories and personal automation.
• Use an organization token for shared builds and releases targeting organization repositories.

Shared CI should use an organization-owned automation token. Give it access only to the required namespaces or repositories and choose Reader or Publisher as needed.

rvs acts for the account that owns the token, so a job does not select an account. Run rvs status in a job to confirm the account.

Store the secret

Save the token as a masked secret named RVS_TOKEN in the CI platform. Expose it only to jobs that publish or install packages.

Do not place the token in repository files, workflow logs, container images, build arguments, cache keys, or artifact names.

Never put RVS_TOKEN in .npmrc, .pypirc, Maven settings, Gradle credentials, Docker authentication, or another native package-tool configuration. Direct use may be accepted when account or organization policy allows it, but Ravenstash documentation does not use or recommend that pattern.

Run package commands through rvs

The shortest CI setup installs rvs, provides RVS_TOKEN, and runs the same wrapped commands developers use. Select the target repository first:

rvs art select platform/packages

Then run the job’s package commands:

# Python
rvs uv sync --locked
rvs uv build
rvs uv --rvs-yes publish

# npm
rvs npm ci
rvs npm --rvs-yes publish

# Maven
rvs mvn --rvs-yes deploy

--rvs-yes skips the interactive publish confirmation. Use it only in a release job that already controls who can run it.

Mint a native registry token

Mint the narrowest token the native package tool needs, then remove the durable credential from the environment before starting that tool:

RVS_NATIVE_TOKEN=$(rvs art token mint \
  --target namespace/repository \
  --format pypi \
  --access read)
unset RVS_TOKEN
export RVS_NATIVE_TOKEN

Use RVS_NATIVE_TOKEN only in the temporary configuration or environment read by the package tool. Choose --access publish for a release job. Do not save the minted value; create a new one in each job.

The rvs pip, rvs uv, rvs twine, rvs npm, and rvs mvn wrappers perform this exchange automatically. They remove RVS_TOKEN from the native child process and pass only the short-lived credential. Do not mint another token when using one of these wrappers.

Rotate without downtime

1. Create a separate replacement token with the required access.
2. Update the CI secret.
3. Run a publish or install test.
4. Delete the old token after every job has moved.

Platform guides

• GitHub Actions
• GitLab CI/CD
• Automation tokens