GitLab CI cli for changesets like its GitHub Action, it creates a merge request with all of the package versions updated and changelogs updated and when there are new changesets on master, the MR will be updated. When you're ready, you can merge the merge request and you can either publish the packages to npm manually or setup the action to do it for you.

Note: environment variables are case-sensitive

• INPUT_PUBLISH - The command to use to build and publish packages
• INPUT_VERSION - The command to update version, edit CHANGELOG, read and delete changesets. Default to changeset version if not provided
• INPUT_COMMIT - The commit message to use. Default to Version Packages
• INPUT_TITLE - The merge request title. Default to Version Packages

• INPUT_PUBLISHED - Command executed after published
• INPUT_ONLY_CHANGESETS - Command executed on only changesets detected
• INPUT_REMOVE_SOURCE_BRANCH - Enables the merge request "Delete source branch" checkbox. Default false.
• INPUT_TARGET_BRANCH -> The merge request target branch. Defaults to current branch
• INPUT_CREATE_GITLAB_RELEASES - A boolean value to indicate whether to create Gitlab releases after publish or not. Default true.
• INPUT_LABELS - A comma separated string of labels to be added to the version package Gitlab Merge request
• INPUT_CWD - A relative path from the repo root to the directory containing package.json and .changeset/. Use this when your npm/yarn workspace lives in a subdirectory of the git repo. Defaults to the repo root.

• PUBLISHED - A boolean value to indicate whether a publishing is happened or not
• PUBLISHED_PACKAGES - A JSON array to present the published packages. The format is [{"name": "@xx/xx", "version": "1.2.0"}, {"name": "@xx/xy", "version": "0.8.9"}]

GLOBAL_AGENT_HTTP_PROXY  # optional, if you're using custom GitLab service under proxy
GLOBAL_AGENT_HTTPS_PROXY # As above but for https requests
GLOBAL_AGENT_NO_PROXY    # Like above but for no proxied requests

# http_proxy, https_proxy, no_proxy environment variables are supported at the same time

GITLAB_HOST # optional, if you're using custom GitLab host, will fallback to `CI_SERVER_URL` if not provided

GITLAB_TOKEN                           # required, token with accessibility to push, package registries, and merge request APIs. Note the CI_JOB_TOKEN does not have sufficient permissions
GITLAB_TOKEN_TYPE                      # optional, type of the provided token in GITLAB_TOKEN. defaults to personal access token. Can be `oauth` if you use Gitlab Oauth (personal access) token
GITLAB_CI_USER_NAME                    # optional, username with accessibility to push, used in pairs of the above token (if it was personal access token). If not set read it from the Gitlab API
GITLAB_CI_USER_EMAIL                   # optional, default `gitlab[bot]@users.noreply.gitlab.com`
GITLAB_COMMENT_TYPE                    # optional, type of the comment. defaults to `discussion`. can be set to `note` to not create a discussion instead of a thread
GITLAB_COMMENT_DISCUSSION_AUTO_RESOLVE # optional, automatically resolve added discussion when changeset is present, if you want to always resolve the discussion, you should actually use `GITLAB_COMMENT_TYPE=note` instead, default `true`
GITLAB_COMMENT_CUSTOM_LINKS            # optional, override the links content referenced in the cli bot comment, use {{ addChangesetUrl }} placeholder for the dynamic URL to add a changeset
GITLAB_ADD_CHANGESET_MESSAGE           # optional, default commit message for adding changesets on GitLab Web UI
DEBUG_GITLAB_CREDENTIAL                # optional, whether to log when setting remote url with sensitive `token` displayed

Create a file at .gitlab-ci.yml with the following content.

stages:
  - comment
  - release

before_script: yarn --frozen-lockfile

comment:
  image: node:lts-alpine
  stage: comment
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: yarn changesets-gitlab comment # comment automatically like https://github.com/changesets/bot

release:
  image: node:lts-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: yarn changesets-gitlab

There are two ways to authenticate with npm when publishing:

1. Trusted Publishers (recommended): Configure npm Trusted Publishers for your GitLab pipeline (see the npm docs: https://docs.npmjs.com/trusted-publishers#supported-cicd-providers). When the pipeline runs, npm will inject an NPM_ID_TOKEN, you do NOT need to set NPM_TOKEN, and no .npmrc file is required—the npm CLI exchanges the identity token automatically.
2. Classic Automation Token: Create an npm automation token (without 2FA on publish) and add it as a custom environment variable in GitLab named NPM_TOKEN.

For any of the methods, create a file at .gitlab-ci.yml with the following content:

stages:
  - comment
  - release

before_script: yarn --frozen-lockfile

comment:
  image: node:lts-alpine
  stage: comment
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: yarn changesets-gitlab comment

release:
  image: node:lts-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: yarn changesets-gitlab
  variables:
    INPUT_PUBLISH: yarn release

By default the GitLab CI cli creates a .npmrc file with the following content when NPM_TOKEN is present and no .npmrc exists (classic token mode):

//registry.npmjs.org/:_authToken=${process.env.NPM_TOKEN}

However, if a .npmrc file is found, the GitLab CI cli does not recreate the file. This is useful if you need to configure the .npmrc file on your own. For example, you can add a step before running the Changesets GitLab CI cli:

script: |
  cat << EOF > "$HOME/.npmrc"
    email=my@email.com
    //registry.npmjs.org/:_authToken=$NPM_TOKEN
  EOF

If you need to add additional logic to the version command, you can do so by using a version script.

If the version script is present, this action will run that script instead of changeset version, so please make sure that your script calls changeset version at some point. All the changes made by the script will be included in the MR.

stages:
  - comment
  - release

before_script: yarn --frozen-lockfile

comment:
  image: node:lts-alpine
  stage: comment
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: yarn changesets-gitlab comment

release:
  image: node:lts-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: yarn changesets-gitlab
  variables:
    INPUT_VERSION: yarn version

If you are using Yarn Plug'n'Play, you should use a custom version command so that the action can resolve the changeset CLI:

stages:
  - comment
  - release

before_script: yarn --frozen-lockfile

comment:
  image: node:lts-alpine
  stage: comment
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: yarn changesets-gitlab comment

release:
  image: node:lts-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: yarn changesets-gitlab
  variables:
    INPUT_VERSION: yarn changeset version

You may also want to run yarn install after the changeset verion command to update the yarn.lock in the version MR. You need to disable immutable lock file setting using an env variable:

release:
  image: node:lts-alpine
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: yarn changesets-gitlab
  variables:
    YARN_ENABLE_IMMUTABLE_INSTALLS: 'false'
    INPUT_VERSION: yarn update-versions

And your update-versions script would be:

{
  "update-versions": "changeset version && yarn install"
}

1stG	RxTS	UnTS

1stG	RxTS	UnTS

Detailed changes for each release are documented in CHANGELOG.md.

MIT © JounQin@1stG.me