Github continued integration of workflow automation package released Npm

Brief introduction

Continuous Integration means that (several times a day) frequent code integrated into the trunk.
It has two main benefits:
1. errors quickly. Each completed a little update, it is integrated into the trunk, you can quickly find errors, positioning errors is relatively easy.
2. To prevent the branch significantly deviate from the trunk. If it is not often integrated, trunk and is continually updated, it will lead to the future integration of difficulty increases, even difficult to integrate.

The purpose of continuous integration is to allow fast iteration of the product, while maintaining high quality. Its core measures, before the code is integrated into the trunk, must pass the test automation. As long as there is a test case fails, it can not be integrated.

GitHub Actions are GitHub continuous integration service, launched in October 2018, now has come to the beta test version is expected to be officially released in November this year.
This article is a simple tutorial demonstrates how to use GitHub Actions automatically publish a npm package.

Implementation steps

1. Create a workflow template

Click on GitHub Actions page Sign upbutton to qualify. Enter github project page you need to publish, Actions icon will appear in the project.
Into the Actions Tab page:

There are various types of workflow templates to choose from. Here we choose Node.js Package click Set up this workflow.
Select the default configuration file:

github project can generate the following documents
.github
| - the Workflows
| - npmpublish.yml.

2. Local yml configuration file

Enter the local project directory to pull the latest code github. Edit npmpublish.yml file, here is my github project lottie-iamge use profile.

name: Node.js Package

on:
  pull_request:
    branches:
      - master
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
      - run: npm ci
      - run: npm test

  publish-npm:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: actions/setup-node@v1
        with:
          node-version: 12
          registry-url: https://registry.npmjs.org/
      - run: npm publish
        env:
          NODE_AUTH_TOKEN: ${{secrets.npm_token}}

Contrast can be seen, in addition to the publish-gpr almost no modifications.
The main structure .yml file is as follows:

name: workflow_name  
on:  
  pull_request:  
    branches:  
      - master  
  push:  
    branches:  
      - master 
jobs:
  job1:
  runs-on: platform
  steps: 
    - uses: action1
    - uses: action2
      with:
        KEY : VALUE
    - run: command1
    - run: command2
      env: 
        KEY: VALUE

  job2:
  needs: job1
  runs-on: platform
  steps: 
    - uses: action1
    - uses: action2
      with:
        KEY : VALUE
    - run: command1
    - run: command2
      env: 
        KEY: VALUE

The following explains the meaning of each part:

name This represents the name of the workflow.
on Represents a trigger condition, such as the aforementioned text indicates workflow is triggered when the master branch and merge push pr.
jobs A collection of work, such as internal jobs job1, job2 indicate the specific tasks you can customize ID as long as no conflict can be.
needs It indicates that the current job dependence and a job Further, the above example is dependent on job2 job1, publish-npm dependent on the build.
runs-on Represents the work where the virtual machine operating system, the current system has an optional ubuntu-latest, ubuntu-18.04, ubuntu-16.04, windows-latest, windows-2019, windows-2016, macOS-latest, macOS-10.14.
stepsThey represent the actions and commands job performed by the collection. How to implement and customize specific action in the future will explain in a special article.

Such structure of the entire workflow on substantially clear.
Here we return to npmpublish.yml file, delete the entire publish-gprjob node (gpr is GitHub Package Registry abbreviations, this feature is currently still in closed beta, the eligibility needs to wait a long time, skip directly here), retaining only build and publish-npm.

Configuration files .npmignore

Add the root directory of the local project .npmignore file.
.Github exclude irrelevant directories and other directory files.
For example, in my project in precludes .github project directory and test files

test/  
.github/  
test.js

4. Add npm token

Open npm account page -> Tokens -> Creat New Token The token copy and paste down and stored locally (token will no longer appear on the page is closed).

Open github project page select Settings -> Secrets -> add a new secret.

The name and the name of the profile consistent. For example, a project profile for

NODE_AUTH_TOKEN: ${{secrets.npm_token}}

Name here to fill npm_token.

5. placed package.json given package-lock.json

Package.json modified version package-lock.json and make it consistent. If no package-lock.json project file, you can do the project npm iwill automatically generate the file.

6. Submission push

Push to submit local projects to GitHub, open the project's Actions page to see the results of continuous integration.