Gitlab

最近离职,一张机票跨越小半个中国,来魔都找了一份喜欢的工作。稳定了就开始继续写东西啦 👯‍

毕业实习的时候在公司里面积极推 Git,考虑到同事的学习成本,在 GogsGitlab 之间,我选了 Gogs,不为别的,只为原生中文 😂。然后一大段时间,我都是在 Github 和 Gogs 这两个平台进行协作的,Gitlab 的大名也不时的在耳边响起。

现在的公司版本控制用的是 Gitlab,所以借此机会我也简单适应了一下,其实和 Github 差不太多,更多的是 Gitlab 提供了一整套的解决方案,其中就包含了 CI/CD。

我还是比较崇尚那句话的:一切能自动化的工作都应该被自动化掉!

.gitlab-ci.yml

在 Gitlab 官网上有很多关于 gitlab CI 如何搭建的介绍,在此我就不多做介绍了,就是照着代码敲到命令行执行即可,现在要讲的是如何配置一个简单的 Gitlab CI 配置文件。

.gitlab-ci.yml 这个文件即是 Gitlab CI 的配置文件,你需要将这个文件放到你 repo 的根目录即可,然后你每次提交, Gitlab 都会自动地去读取执行该文件的内容,如果你提交了一个新的 .gitlab-ci.yml,那 gitlab CI 会使用你刚提交的那份配置文件进行 CI

下面就贴一份简单的用于部署前端项目的 .gitlab-ci.yml 文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
# 这个是我现在项目初期使用的一个配置文件
# 下面我就开始简单的讲一下各个配置的作用
# yml 文件支持注释,像当前文字这样,左侧以 # 号开头即为注释

# 下面这个是表示,我们运行 CI 用的镜像是 kkarczmarczyk/node-yarn:latest
# 因为我司的 CI 任务是选的在 Docker 上运行,所以每次执行 CI 任务的时候,都会新启动一个 Docker 容器
# 然后在容器中依次执行下面的命令
# 注意:不同的 stage 执行前,都会将该容器环境设置为初始化时的状态
image: kkarczmarczyk/node-yarn:latest

# 定义全局的缓存策略,如上所说,每个不同的 stage,CI 都会重新启动一个新的容器,所以我们之前 stage 中的文件都会消失
# 那在前端开发中,就意味着每个 stage 都要重新完整装一次 node_modules,这样的时间和网络成本都不低
# 所以我们选择将这些文件缓存下来
# 但是,缓存也要讲究实效性,例如我在第二次的提交中增加了一个库,那第二次的 CI 就不能再重复使用上一次的 node_modules 缓存了
# 在 .gitlab-ci.yml 中,我们通过设置 cache 的 key 来区分不同的缓存
cache:
# 该 Key 的值为一个系统变量,gitlab 在运行的时候内置了不少的系统变量供使用,下面的配置表示
# 以每次提交的 ref 号为 key 来区分不同缓存,效果就是同一次提交中的所有 stage 用同一份 cache
key: ${CI_COMMIT_REF_SLUG}

# 定义 stage,stage 可以简单的理解为“步骤”,会顺序执行,如果上一步错了,那不会继续执行下一步
# 比如像下面我定义的,第一步先初始化,第二步检查代码规范,第三步进行单元测试,第四步构建,第五步就直接将项目部署到服务器
stages:
- init
- lint
- unit_test
- build
- deploy

# 这个是某个任务的名称,你可以随意起名
install_packages:
# 指定该任务所属的步骤,每到一个步骤,该步骤所对应的所有任务都会并行执行
stage: init
# 指定要缓存的文件以及文件夹
cache:
# 这个属性是 gitlab 比较新版本里面加的特性,意思是在这一步,我只上传这个缓存,我不会拉取该缓存
policy: push
# 指定缓存的内容,在下面我缓存了 node_modules 这个文件夹,你还可以在下面继续添加文件或者文件夹
paths:
- node_modules/
# 该任务要运行的脚本,顺序执行
# 都是 bash 命令
# 默认当前目录就是 repo 的根目录
script:
# 我先列出所有文件的列表,便于 script 出错后进行调试
- "ls -la"
# 设置 yarn 的源,会快一些
- 'yarn config set registry "https://registry.npm.taobao.org"'
# 安装所有依赖,也就是 node_modules
- "yarn"

# 执行完 init 这个 stage(步骤)后,我们的 node_modules 目录就缓存下来了
# 然后我们就开始执行代码检查
lint_code:
# 对应的步骤是代码检查,可以多个任务指向同一个 stage,这些任务将会被并行执行
stage: lint
# 定义缓存
cache:
# 下面的配置指示,我们当前只拉取缓存,不上传,这样会节省不少时间
policy: pull
# 指定要缓存的文件/文件夹
paths:
- node_modules/
# 该任务要运行的 bash 脚本
script:
- "ls -la"
- "yarn lint"

# 单元测试
unit_test:
# 隶属于 单元测试 这个步骤
stage: unit_test
# 同 lint_code 任务,拉取缓存,我们就不用再重新下载 node_modules 了
cache:
policy: pull
paths:
- node_modules/
# 执行 bash 命令
script:
- "ls -la"
- "yarn test:unit"

build:
stage: build
cache:
policy: pull
paths:
- node_modules/
# artifacets 是打包你指定的文件或者文件夹,然后你可以通过 gitlab 的页面进行下载的
artifacts:
# artifacets 的名字
name: "dist"
# artifacets 的过期时间,因为这些数据都是直接保存在 Gitlab 机器上的,过于久远的资源就可以删除掉了
expire_in: 60 mins
# 制定需要打包的目录,这里我把 dist 目录给打包了,准备发布到服务器
paths:
- dist/
script:
- "ls -la"
- "yarn build"

# 部署任务
deploy:
stage: deploy
# 该命令指定只有 master 分支才能够执行当前任务
only:
- master
# 部署脚本,在下面的代码中,我用到了很多类似 ${AMAZON_PEM} 的变量,由于我们的私钥、Ip 都算是不宜公开显示的信息,
# 所以我用到了 Gitlab 的变量工具,在 repo 的 CI/CD > Environments 中,这些变量值只有项目管理员才有权限访问
script:
- "ls -la"
- "ls -Rl dist"
- 'echo "${AMAZON_PEM}" > amazon.pem'
- "chmod 600 amazon.pem"
- "scp -o StrictHostKeyChecking=no -i amazon.pem -r dist/* ${AMAZON_NAME_IP}:/usr/share/nginx/html/"

坑 s

在使用的过程中,还是经历了一些坑的,也记录下来

  • 公司的 Gitlab 估计是版本问题,cache 基本是失效的,所以无奈,我直接添加了一个 before_script 来在每个 jobs 执行前都完整安装一次 node_modules
  • 将服务器私钥保存到 Gitlab 的 CI 变量中后,本想通过 echo ${AMAZON_PEM} > amazon.pem,把私钥存储为文件使用,结果发现 echo 出来的文本没有了换行,最终解决办法是 echo "${AMAZON_PEM}" > amazon.pem(就只需要加两个引号)