CI/CD

CI jobs can install LPM.dev Registry packages, publish a package, or decrypt an env. These operations do not share one credential.

Operation	Authentication	Scope
Install private or entitled packages	LPM_TOKEN	Read access for the token owner or organization
Publish with a static token	LPM_TOKEN	Publish access granted to that token
Publish with a Trusted Publisher	GitHub Actions or GitLab CI OIDC	One configured package
Pull an encrypted environment	Env OIDC policy	One env, repository policy, and environment

Install LPM CLI before using its package, publishing, or environment commands:

npm install -g @lpm-registry/cli

For reproducible workflows, pin the package to a reviewed version. See the LPM CLI CI/CD guide for installation choices, lockfile behavior, caching, and security gates.

Install Packages with a Read Token

Create a read-scoped token from personal token settings or the organization's token settings. Store it as LPM_TOKEN in the CI provider's encrypted secret store.

LPM CLI reads the token directly:

name: Build
on: push

permissions:
  contents: read

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm install -g @lpm-registry/cli

      - name: Install from the lockfile
        run: lpm ci
        env:
          LPM_TOKEN: ${{ secrets.LPM_TOKEN }}

      - run: npm test

Commit lpm.lock. Commit lpm.lockb when LPM CLI writes it. Do not cache node_modules.

Cache the LPM CLI store when the workflow needs reusable package data.

npm, pnpm, or yarn

An npm-compatible client needs scoped .npmrc routing:

- name: Configure LPM.dev Registry
  run: lpm setup ci npmrc
  env:
    LPM_TOKEN: ${{ secrets.LPM_TOKEN }}

- run: npm ci
  env:
    LPM_TOKEN: ${{ secrets.LPM_TOKEN }}

The generated .npmrc is job-local and can contain a live token. Do not upload it as an artifact or include it in a cache.

GitLab CI, Bitbucket Pipelines, and other providers use the same LPM_TOKEN contract. Protect the variable and restrict it to trusted branches or deployment environments.

Publish with a Trusted Publisher

A Trusted Publisher lets GitHub Actions or GitLab CI publish one existing package without storing a long-lived publish token.

Configure the Package

1. Publish the package once with an authorized LPM CLI session or publish token.
2. Open the package in the LPM.dev Registry dashboard.
3. Open Trusted Publishers.
4. Choose GitHub Actions or GitLab CI.
5. Enter the repository owner and repository name.
6. Enter the immutable numeric repository ID or project ID.
7. Enter the workflow filename or CI-config filename.
8. Enter an exact ref or a tag pattern. Use refs/tags/v* for release tags that start with v.
9. Enter an environment if the workflow uses one.
10. Save the configuration.

For GitHub, get the repository ID with this command:

gh api repos/OWNER/REPOSITORY --jq .id

GitLab shows the project ID on the project overview page. These numeric IDs do not change when a repository name changes.

The numeric ID, workflow filename, and allowed ref must match the verified provider claims. The optional environment must also match when configured.

An exact branch or tag ref permits one ref. A tag pattern permits one literal tag prefix.

The only wildcard form is one final *, such as refs/tags/v*. Branch wildcards and other wildcard positions are invalid.

LPM compares the tag prefix as text. It does not interpret the pattern as a regular expression.

CAUTION: Legacy configurations without an immutable ID and allowed ref cannot publish. Remove each disabled configuration and create it again with both values.

Pull-request and merge-request jobs cannot exchange Registry tokens. Use a trusted push, release, manual, scheduled, or supported provider-triggered workflow.

GitHub Actions

name: Publish
on:
  push:
    tags:
      - "v*"

permissions:
  id-token: write
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22

      - run: npm install -g @lpm-registry/cli
      - run: npm ci
      - run: npm test
      - run: lpm publish -y

GitHub exposes an identity-token runtime to jobs with id-token: write. LPM CLI requests a Registry-audience identity token and exchanges it for a short-lived publish token restricted to the configured package.

Configure refs/tags/v* as the allowed ref. A tag such as v1.2.3 then starts the workflow and matches the publisher.

If npm ci also needs private LPM.dev Registry dependencies, give only that install step a read-scoped LPM_TOKEN. The final lpm publish step does not need the static publish secret.

GitLab CI

publish:
  stage: publish
  image: node:22
  id_tokens:
    LPM_OIDC_TOKEN:
      aud: https://lpm.dev
  script:
    - npm install -g @lpm-registry/cli
    - npm ci
    - npm test
    - lpm publish -y
  rules:
    - if: '$CI_COMMIT_TAG =~ /^v/'

LPM_OIDC_TOKEN is the canonical GitLab variable for Registry exchange. Configure refs/tags/v* as the allowed ref for this example.

The Trusted Publisher configuration must name the matching .gitlab-ci.yml file or configured CI file.

Verify Trusted Publishes

The package's Trusted Publishers page lists recent OIDC publishes with the version and verified provider provenance. Package security history also identifies whether a release used OIDC or a static token.

Publish with a Static Token

For Bitbucket Pipelines or another provider without supported Trusted Publisher identity, store a publish-scoped token as LPM_TOKEN:

lpm publish -y

Limit the token to the required automation context. Protect the CI variable. Rotate or revoke the token after suspected exposure.

Environment OIDC Is Separate

lpm env pull --oidc uses an env-specific policy and encrypted key escrow. It does not grant package installation or publishing rights:

lpm env pull --oidc --env=production --output=.env

Configure that workflow through OIDC for CI. Platform environment synchronization is documented under Platform Integrations.

Sigstore provenance is another separate LPM CLI feature. See the LPM CLI publish reference for --provenance, quality gates, dry runs, and multi-registry publishing.

See Also

• Authentication — LPM CLI sessions and read-only project access.
• Deployment Platforms — Build-time package access on hosted platforms and Docker.
• LPM CLI setup reference — Exact lpm setup commands and generated files.
• LPM CLI CI/CD guide — Lockfiles, caches, gates, and command flags.