Let’s imagine a development scenario

  1. We use TS for the development kit
  2. When we’re done, we merge the code and release tag it and archive it
  3. Triggers the CI to perform the remote build action
  4. Publish the build results to our NPM package management

This article describes how to publish front-end packages to NPM using CI/CD under GitLab, allowing NPM packages to be associated with the repository, while eliminating the manual NPM Publish action

If you’re not in gitLab, don’t worry, the script section will still help you a lot

For those who do not use Gitlab, you can use this article to do the basic Gitlab building to play with CI/CD in Gitlab (juejin. Cn)

preparation

1. Create a code repository

Please refer to the code of this warehouse, please delete the gitlab-ci.yml file oh ~ click here to download

1. Generate an NPM token for backup

  1. Log in to the NPM official website to obtain the token

Creating a token

Save the created token for use. Find profile and open 2FA

4. Set the token as an environment variable

To register for the first time need to verify email NPM publish an error: 403 Forbidden – PUT https://registry.npmjs.org – SegmentFault think no

Configure CI/CD

1. Configure the CI file

A gitlab-ci.yml file looks like this. Build represents the name of the build phase, which is a stage, and script represents the script work for that phase. Here, simple NPM I and TSC build work are done. The output directory and configuration for the build are mainly in the tsconfig.json of the project

image: node:latest

build:
  script:
  - npm install
  - ./node_modules/typescript/bin/tsc -p ./tsconfig.json
Copy the code

Once saved, you will see the task in progress in CI/CD

2. Specify that only branches trigger builds

The ABOVE CI logic will be applied to all branches and will be started once the commit action occurs. This is obviously inconsistent with our requirements. We want the build action to take place only when we tag, so we need to add the only limit to our build stage so that it can only work on some branches

    only:
    - develop
    - release
    - master
    - /^dev_[0-9]+(? : [0-9] +) + $/ # regular expression
Copy the code

With the only syntax, we can either write the name of the dead branch or tag directly, or we can use regular expressions to match. In this case, we write the version wildcard

    only:
      - /^\d+\.\d+\.\d+$/
Copy the code

When we type a tag in a format similar to 1.0.0, we trigger the build. We can also add a little tail, such as

    only:
      - /^\d+\.\d+\.\d+$/ # This is the version
      - /^\d+\.\d+\.\d+-beta-.*/ # beta version
Copy the code

3. Replace the version number of package.json with the tag number

The version number above NPM is matched according to the version in package.json, so we need to modify the version number before the official publish. Some partners may manually modify the package.json file before tagging. There is no problem, here we directly modify the script code in CI, and the related script is as follows

- file=`cat ./package.json` # Read the file and assign it to the file variable
- echo ${file/\"version\":\ \ "1.0.0 \" / \ "version \" : \ \"`git describe`\"} > ./package.json
Copy the code

Git Describe is used to get the current repository description, which is the name of the branch in the CI that is executed after tag, and can also be handled using gilab variables

Echo xx > filePath output xx contents to the specified file, directly overwrite

${string/aa/bb} ${string/aa/bb} ${string/aa/bb} ${string/aa/bb} ${string/aa/bb} ${string/aa/bb}

Some slashes are mainly used for escaping and can be tested locally

Echo ${string / \ "version \" : \ \ "1.0.0 \" / \ "version \" : \ \ "` git the describe ` \"} >. / package. JsonCopy the code

4. Clear unnecessary directories

Before uploading, we can clean up our source code and some process files

- rm -rf src # I used the project source code in SRC
- rm -rf node_modules # Dependencies do not need to be uploaded together
Copy the code

5. Tonpm publish

Finally, configure the token to ensure the NPM Publish permission

- echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
Copy the code

Execute the release, and the entire file will look like

# This file is a template, and might need editing before it works on your project.
# Official framework image. Look for the different tagged releases at:
# https://hub.docker.com/r/library/node/tags/
image: node:latest

build:
  script:
  - echo "//registry.npmjs.org/:_authToken=${NPM_TOKEN}" > .npmrc
  - npm install
  - ./node_modules/typescript/bin/tsc -p ./tsconfig.json
  - rm -rf src
  - rm -rf node_modules
  - string=`cat ./package.json`
  - echo ${string/\"version\":\ \ "1.0.0 \" / \ "version \" : \ \"`git describe`\"} > ./package.json
  - npm publish
  
  only:
    - /^v.*/ # My version of the play is the beginning of V
Copy the code

When this is done, you will see the results of the release. Note that when publishing public packages, you need to remove the private line from package.json

The advanced

  1. Due to security restrictions, most of the company’s subcontracts cannot be directly attached to the public network, so it is necessary to push packages into private package management. You can use A lightweight open source private NPM proxy registry | Verdaccio system as A private package management, according to the above process after completing treatment

  2. In theory, not only can we automatically publish the NPM package, but when submitting the merge request, we can automatically print a tag from the master, which in turn triggers a publish operation

other

  1. You do not need to configure the token if your Runner installation already has NPM Login action

reference

  1. Shell String substitution – jianshu.com
  2. The use of the token
  3. Continuously Deploying an NPM Package with GitLab CI/CD (webbureaucrat.gitlab.io)