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 packagesINPUT_VERSION- The command to update version, edit CHANGELOG, read and delete changesets. Default tochangeset versionif not providedINPUT_COMMIT- The commit message to use. Default toVersion PackagesINPUT_TITLE- The merge request title. Default toVersion Packages
INPUT_PUBLISHED- Command executed after publishedINPUT_ONLY_CHANGESETS- Command executed on only changesets detectedINPUT_REMOVE_SOURCE_BRANCH- Enables the merge request "Delete source branch" checkbox. Default false.INPUT_TARGET_BRANCH-> The merge request target branch. Defaults to current branchINPUT_CREATE_GITLAB_RELEASES- A boolean value to indicate whether to create Gitlab releases after publish or not. Default true.
PUBLISHED- A boolean value to indicate whether a publishing is happened or notPUBLISHED_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 GITLAB_TOKEN_TYPE # optional, type of the provided token in GITLAB_TOKEN. defaults to personal access token. can be `job` if you provide the Gitlab CI_JOB_TOKEN or `oauth` if you use Gitlab Oauth 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_ADD_CHANGESET_MESSAGE # optional, default commit message for adding changesets on GitLab Web UI DEBUG_GITLAB_CREDENTIAL # optional, default `false`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 only: merge_requests script: yarn changesets-gitlab comment # comment automatically like https://github.com/changesets/bot release: image: node:lts-alpine only: main script: yarn changesets-gitlabBefore you can setup this action with publishing, you'll need to have an npm token that can publish the packages in the repo you're setting up the action for and doesn't have 2FA on publish enabled (2FA on auth can be enabled). You'll also need to add it as a custom environment variable on your GitLab repo with the name NPM_TOKEN. Once you've done that, you can 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 only: merge_requests script: yarn changesets-gitlab comment release: image: node:lts-alpine only: main script: yarn changesets-gitlab variables: INPUT_PUBLISH: yarn releaseBy default the GitLab CI cli creates a .npmrc file with the following content:
//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 EOFIf 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 only: - merge_requests script: yarn changesets-gitlab comment release: image: node:lts-alpine only: main script: yarn changesets-gitlab variables: INPUT_VERSION: yarn versionIf 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 only: - merge_requests script: yarn changesets-gitlab comment release: image: node:lts-alpine only: main script: yarn changesets-gitlab variables: INPUT_VERSION: yarn changeset versionYou 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 only: main script: yarn changesets-gitlab variables: YARN_ENABLE_IMMUTABLE_INSTALLS: 'false' INPUT_VERSION: yarn update-versionsAnd 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.