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

10次阅读

共计 6433 个字符,预计需要花费 17 分钟才能阅读完成。

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

👉🏻中文文档 -14.8-pre

👉🏻Gitlab 版本—12.9

前置常识

  1. yaml 语法,教程👉🏻YAML 入门教程
  2. Docker 相干常识,教程👉🏻Docker 教程
  3. linux 命令,教程👉🏻Linux 命令大全

自定义配置目录

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

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

流水线配置

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

  1. 全局配置,运行在单个 stage 之前或者之后。
  2. 单个 stage 配置

构造大抵能够如下:

# 指定脚本执行的镜像环境,如下为 node 环境为 14.17.1
image: 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

tags

指定 gitlab 在执行脚本时应用哪个 runner。

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 & exceptrules: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 时,pathsfiles 的文件 / 目录都是以我的项目的根目录为绝对地位的,在 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 下的 filespaths配置多个门路 / 文件来实现。

禁用缓存

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

继承缓存

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

cache: &global_cache
  key: $CI_COMMIT_REF_SLUG
  paths:
    - node_modules/
    - public/
    - vendor/
  policy: pull-push

job:
  cache:
    # 继承全局缓存
    <<: *global_cache
    # 重写缓存策略
    policy: pull

回退缓存键

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

variables:
  CACHE_FALLBACK_KEY: fallback-key

job1:
  script:
    - echo
  cache:
    key: "$CI_COMMIT_REF_SLUG"
    paths:
      - binaries/

手动革除缓存

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

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

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

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

编写 .gitlab-ci.yml 根本流程,如下:

image: node:14.17.1

before_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: 0

after_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}, 分支名为 master
const env = process.argv[2]

// 拼接命令,执行 npm publish,打 tag
function 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 包的示例,感激浏览!

正文完
 0