关于javascript:Gitlab-CICD教程及npm包构建发布实战

!!!实际过程中请注意文档版本号跟你理论应用Gitlab的版本号

中文文档-14.8-pre

Gitlab版本—12.9

前置常识

yaml语法，教程YAML 入门教程
Docker相干常识，教程Docker教程
linux命令，教程Linux 命令大全

自定义配置目录

默认配置文件目录是在mono repo的根目录，文件名为.gitlab-ci.yml。

若须要自定义设置CI脚本文件的门路，如下：

流水线配置

.gitlab-ci.yml文件中对流水线配置大抵能够分为2个环节：

全局配置，运行在单个stage之前或者之后。
单个stage配置

构造大抵能够如下：

# 指定脚本执行的镜像环境，如下为node环境为14.17.1image: node:14.17.1# 单个job执行之前执行before_script:  - echo '====== 筹备构建中 ========='# 配置单个stage的执行程序，串行stages:  - install  - build# 单个stage配置# 装置依赖npm_install:  only:    - master  stage: install  script:    - yarn    - ls -al# 单个stage配置# 构建webpack_build:  only:    - master  stage: build  script:    - yarn build# 单个job全副执行完之后执行after_script:  - echo "====== 构建完结 ========="

重要概念

Pipeline

流水线，一次流水线相当于一次构建工作，外面能够蕴含多个阶段，比方install -> eslint -> build -> deploy等流程 ;

stages

示意构建阶段，每个stage串行同步执行。一旦有一个stage中的一个job失败了，那么下一个stage的工作便不会执行。如果以后stage定义了多个工作，那么其中一个工作失败，另外一个工作还是会被继续执行。然而只有当所有 stages 胜利实现后，该构建工作 (Pipeline) 才算胜利。

jobs

job示意某个stage外面执行的工作，一个stage外面能够定义多个job 。

jobs有如下特点 :

雷同 stage 中的jobs 会并行执行
雷同 stage 中的 jobs 都执行胜利时，该 stage 才会胜利
如果任何一个job 失败，那么该 stage 失败，即该构建工作 (Pipeline) 失败

gitlab runner

执行构建工作的一个服务，外面蕴含了继续集成的的环境，个别由docker创立。它能够在不同的主机上部署，也能够在同一个主机上设置多个gitlab-runner ,还能够依据不同的环境设置不同的环境，比方咱们须要辨别研发环境，测试环境以及正式环境等。

关键字

image

CI/CD脚本运行环境的docker镜像，镜像就是一种文件存储模式，能够了解为是一个环境的汇合，内含多种文件。如指定node环境镜像：

# 最新版本node环境image: node:@latest

before_script

在单个stage执行之前执行的脚本内容，内容以数组模式配置，如上例子中：

before_script:  - echo '====== 筹备构建中 ========='

stages

CI容许咱们进行自定义的流水线阶段配置，能够将一个流水线拆分为多个阶段（stage），stages会串行执行。

stages:  - install  - build

script

执行脚本，脚本内容以数组模式配置。如上例子中stage为npm_install阶段执行的脚本为：

script:    - yarn    - ls -al

先执行yarn命令装置依赖，完结后查看了当前目录下文件及目录的具体信息，是个串行执行的过程。

cache

缓存多个流水线工作之间共用的文件和目录，缓存相干概念下文详情讲述。

only & except

设置流水线工作执行机会：应用 only 来定义job何时运行，应用 except 定义job不运行的工夫。

指定分支触发执行机会
```
job:  only:    - branches@gitlab-org/gitlab  except:    - main@gitlab-org/gitlab    - /^release/.*$/@gitlab-org/gitlab
```
此示例为 gitlab-org/gitlab 上的所有分支运行 job，除了 main 和以 release/ 结尾的分支。

在合并申请时触发

job1:  script:    - echo "This job runs in merge request pipelines"  only:    - merge_requests

在push的时候触发

job1:  script:    - echo "branch push"  only:    - pushes

手动触发
在Gitlab Runner/pipeline外面点击run pipeline时触发
```
job1:  only:    - web
```
依据git提交音讯或者判断分支触发执行机会
```
build:  script:       - yarn build  except:    variables:      - $CI_COMMIT_MESSAGE =~ /test/ || $CI_COMMIT_BRANCH == "main"
```
git commit 音讯为”test“的push跟提交分支为”main“的push不触发此job。
依据文件批改判断执行机会
```
build:  script: yarn build  except:    changes:      - "*.md"
```
只有有md文件批改就不执行此job。

retry

job重试次数，默认为0，最大重试次数为2，其中when可设置在特定失败起因的状况下执行。

rules:if

此字段能够在单个流水线job或者workflow字段下进行配置。

rules关键词下能够进行if语句配置，如果if满足的话可执行某些自定义配置。

rules:  - if: $CI_COMMIT_REF_NAME =~ /feature/

留神: only & except和rules:if都是用来决定单个job执行机会的，在配置时只能存在一个，否则会报错。

workflow

和rules配合用来管制流水线的执行动作，在最外层进行配置，workflow: rules 承受这些关键字：

if：查看此规定以确定何时运行流水线。
when：指定当if为 true 时要做什么。
- 要运行流水线，请设置为 always。
- 要阻止流水线运行，请设置为 never。
variables：如果未定义，则应用在别处定义的变量。实用版本13.11 ~14.0

当没有规定为 true 时，流水线不会运行。

以下示例中，前两天规定都匹配到不执行机会，当else时，流水线执行。

workflow:  rules:    - if: '$CI_PIPELINE_SOURCE == "schedule"'      when: never    - if: '$CI_PIPELINE_SOURCE == "push"'      when: never    - when: always

when

管制上一个stage胜利或者失败时，以后stage的行为。

on_success(默认值): 上一个stage胜利了才会执行当阶段工作，或者之前失败的工作配置了allow_failure: true。
on_failure ：只有上一个阶段工作失败了才会执行当前任务。
always：无论上一个阶段的jobs状态如何，都会触发以后阶段的工作。
never：不运行当前任务。
manual：在gitlab网页中手动点击触发。

模块化

应用关键字include引入其余yml文件中的配置。

include:  - '/yml/job1_install.yml'  - '/yml/job2_lint.yml'  - '/yml/job3_build.yml'  - '/yml/job4_deploy.yml'

缓存

重要概念

在 GitLab CI/CD 中，咱们所应用的 runner 是以 docker 的模式运行不同的工作。一般的 cache 机制（即不指定URL，No URL provided, cache will not be downloaded from shared cache server. Instead a local version of cache will be extracted. ），其 cache 是存储在本地，所以如果两个 job 理论运行的地位是不在宿主机上的，其相互之间的缓存是无奈共享的。

分布式缓存

分布式缓存须要runner配置反对，开启后须要在cache中配置s3ServerAddress、s3BucketName等信息进行缓存跨runner共享。

缓存门路

在配置cache时，paths跟files的文件/目录都是以我的项目的根目录为绝对地位的，在store cache的时候也是以我的项目名辨别缓存门路的，利用缓存的时候会在我的项目下配合key值去利用缓存，即便是分布式缓存也是依照这个策略。

缓存文件信息上会有最初更新工夫（重要信息）、文件权限、cache中设置的key等，其中更新工夫跟缓存策略有分割，如果歹意篡改服务器工夫，可能会呈现依赖前后不统一导致打进去的包不合乎预期的状况。

缓存绑定文件

缓存绑定到以后版本的文件。当这些文件之一发生变化时，将计算一个新的缓存键并创立一个新的缓存，如下：

cache-job:  script:    - echo "This job uses a cache."  cache:    key:      files:        - Gemfile.lock        - package.json    paths:      - vendor/ruby      - node_modules

此时的 key 是依据最近更改了每个列出的文件的提交计算得出的 SHA。如果在任何提交中都没有更改任何文件，则key就是默认值 default。

多文件缓存

cache能够配置多个key，实用于13.10 ~ 13.12版本，其余版本能够在key下的files和paths配置多个门路/文件来实现。

禁用缓存

应用cache: {}来禁用缓存。

继承缓存

缓存配置可复用的状况下应用继承写法，能够在以后job下笼罩（重写）某个策略或者设置优先级

cache: &global_cache  key: $CI_COMMIT_REF_SLUG  paths:    - node_modules/    - public/    - vendor/  policy: pull-pushjob:  cache:    # 继承全局缓存    <<: *global_cache    # 重写缓存策略    policy: pull

回退缓存键

13.4版本以上可利用回退缓存键，性能相似缓存备份。你能够应用 CACHE_FALLBACK_KEY 变量来指定一个备份缓存key，他会在你指定key的缓存不存在时去查找利用备份缓存。

variables:  CACHE_FALLBACK_KEY: fallback-keyjob1:  script:    - echo  cache:    key: "$CI_COMMIT_REF_SLUG"    paths:      - binaries/

手动革除缓存

您能够在 GitLab UI 中革除缓存：

在顶部栏上，抉择 菜单 > 我的项目 并找到您的我的项目。
在左侧边栏上，抉择 CI/CD > 流水线 页面。
在右上角，抉择 革除 Runner 缓存。

在下一次提交时，您的 CI/CD 作业应用新的缓存。

实战：构建公布组件库到npm仓库

编写.gitlab-ci.yml根本流程，如下：

image: node:14.17.1before_script:  - echo '====== 筹备构建中 ========='stages:  - install  - lint  - build  - deploy### 配置缓存cache:  key:    files:      - package.json      - packages/ghost-weapp-ui/package.json  paths:    - node_modules/    - packages/ghost-weapp-ui/node_modules/    ### 间接缓存.npm，.npm中缓存了所有依赖，因为gitlab缓存是分我的项目的，所以两种办法集体感觉没有什么区别    # - .npm/# eslint检测job_lint:  only:    - master  stage: lint  before_script:    - echo 'eslint检测'    - ls -a  script:    - cd packages/ghost-weapp-ui    - ls -a    - yarn lint    - echo 'eslint检测实现'  retry: 0  when: 'on_success'# 装置依赖job_install:  only:    - master  stage: install  before_script:    - echo '装置依赖'  script:    - yarn config set registry https://registry.npm.taobao.org/    - yarn install    - cd packages/ghost-weapp-ui    - ls -a    - yarn install    - ls -a    - echo '依赖装置实现'  retry: 0# 打包编译job_build:  only:    - master  stage: build  before_script:    - echo '开始打包'  script:    - cd packages/ghost-weapp-ui    - ls -a    - yarn    - ls -a    - yarn build    - echo '构建实现'  when: 'on_success'  retry: 0# 公布job_deploy:  only:    - master  stage: deploy  before_script:    - echo '更新补丁版本，筹备公布'  script:    - cd packages/ghost-weapp-ui    - node deploy.js ${CI_COMMIT_REF_NAME}  when: 'on_success'  retry: 0after_script:  - echo "====== 公布实现 ========="

编写部署脚本，其中次要是模仿npm login流程替换为应用token进行登录并且执行npm publish，公布到npm的流程。

const fs = require('fs')const path = require('path')const os = require('os')const { exec } = require('child_process')// 替换为本人npm账号的authToken// token获取办法：vim ~/.npmrc const npmrcText = `registry=https://registry.npmjs.org/home=https://www.npmjs.org//registry.npmjs.org/:_authToken=${authToken}`// 获取命令中第三个参数，此例子中为'master'// node deploy.js ${CI_COMMIT_REF_NAME}, 分支名为masterconst env = process.argv[2]// 拼接命令，执行npm publish，打tagfunction deploy() {    fs.writeFileSync(path.resolve(os.homedir(), '.npmrc'), npmrcText)    const argsArray = ['publish'].concat(['--tag', env === 'master' ? 'latest' : 'beta'])    execa('npm', argsArray);}async function execa(a, arry = []) {    return new Promise((resolve, reject) => {        exec(`${a} ${arry.join(' ')}`, (err, stdout, stderr) => {            if (err) {                console.error(err);                reject(err);            }            resolve(stdout)        })    })}deploy();

执行后果：

收到npm公布胜利反馈邮件：

以上就是gitlab CI/CD的相干知识点以及实战公布npm包的示例，感激浏览！

前置常识

自定义配置目录

流水线配置

重要概念

Pipeline

stages

jobs

gitlab runner

关键字

image

tags

before_script

stages

script

cache

only & except

retry

rules:if

workflow

when

模块化

缓存

重要概念

分布式缓存

缓存门路

缓存绑定文件

多文件缓存

禁用缓存

继承缓存

回退缓存键

手动革除缓存

实战：构建公布组件库到npm仓库