Using glpkg in GitLab CI

Token

glpkg reads the token from the GITLAB_TOKEN environment variable.

1. Create a project or group access token (or a personal access token for a bot user):
   • install only: read_api (and read_registry)
   • publish: api
2. Add it under Settings → CI/CD → Variables as GITLAB_TOKEN, masked (and protected if only protected branches publish).

note

CI_JOB_TOKEN is not supported. Use an access token as above.

Do not run glpkg config save in a job. A saved token file takes precedence over GITLAB_TOKEN.

Install

Commit glpkg.lock.json. In CI, a whole-project install reads every source from it:

install:
  image: node:20
  script:
    - npm install -g @glpkg/cli
    - glpkg install
  cache:
    paths: [node_modules/]

If a direct dependency has no recorded source, the job fails with No install source recorded for: …. Record it locally with glpkg lock set and commit the lock.

Publish

glpkg publish needs git and the GitLab CLI glab in the image, and a clean checkout. glab reads GITLAB_TOKEN from the environment.

publish:
  image: node:20
  rules:
    - if: $CI_COMMIT_TAG
  before_script:
    - npm install -g @glpkg/cli
    # install glab, see https://gitlab.com/gitlab-org/cli#installation
  script:
    - glpkg install
    - glpkg publish --git-tag false --push false

• --git-tag false --push false keeps the job from committing, tagging or pushing. Set the version in package.json before tagging, or bump in the job without pushing.
• Publish refuses a dirty working tree. If glpkg install in the job changes tracked files (for example glpkg.lock.json or package-lock.json), commit the updated files from a local install first, or add --force.
• Use glpkg publish --dry-run in merge request pipelines to check the package.
• A dev publish writes <version>-dev.<timestamp> into package.json in the job's checkout, which is fine in CI.

Self-managed GitLab

Set IST_GITLAB_HOST as a CI variable. See Self-managed GitLab.

Global CLI tools in CI

  script:
    - glpkg install -g @your-org/cli --group your-org

Global installs always need --group or --external.