使用gitlab ci实现前端资源自动发布

描述

web端的特点是灵活,随时可上线。带来的问题就是上线重复次数特别多,这个需要简化。

现在很多公司在内网搭起了自己的gitlab。

如何能省事儿呢?代码提交后依靠gitlab的ci来自动build代码并部署是希望达到的效果。毕竟我现在提交代码大部分时候就两条命令。

1
2
3
$ gcam <msg>

$ gp

这是用了Oh My Zsh 的git插件的效果。

可以做这样一个约定,提交代码到gitlab,如果提交的分支是一个特殊格式的分支名那么静态资源发布系统自动拉取代码build,并且将build的结果发布到日常环境供测试同学来使用。如果是打一个特殊格式的tag那么自动build发布到CDN。

实践

需要在项目根目录加一个叫做 .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
#
# 请勿修改或删除
#

# 理解为阶段,相同阶段的并行执行,不同阶段顺序执行,先后顺序是阶段的执行顺序。
stages:
- build

# job名字,随意
daily-build:
stage: build # 此job属于哪个阶段
only: # 此job匹配哪个branch或者tag或者trigger
- <一个匹配日常分支的正则>
except:
- tags # 此job忽略tag
- triggers # 此job忽略trigger
script:
- <日常build要执行的命令> # job执行的脚本

# job名字,随意,大概意思同上
publish-build:
stage: build
only:
- <一个匹配tag名字的正则>
except:
- branches
- triggers
script:
- <正式build要执行的命令>

解释都写在注释中。千万不要以为是gitlab来执行上面这些任务,gitlab只是任务的发起方,你还需要给gitlab注册执行任务的runner,他们才是干活的,gitlab和runner之间的关系下图。


gitlab-runner以前叫做gitlab-ci-multi-runner,后来发布到10版本的时候改了名字。看下面的兼容表来决定自己要安装的版本,我们使用的是gitlab9.x,所以选择了最新的10版本的gitlab-runner。


runner一般不跟gitlab放在同一台机器上,安装过程参考gitlab官方文档,毕竟每个系统的安装方式是有差异的。

安装好之后执行如下命令将runner注册给gitlab,命令是交互式的,很好懂。

1
$ gitlab-runner register

大概流程如下,还有其他的根据实际情况填写就行。

  1. 输入gitlab地址
  2. 输入项目的token,这个需要到gitlab repo中的CI部分找到。
  3. 给runner命名,用于在gitlab端标识。

注册好之后还要把runner的服务启动起来。以macOS为例,执行如下两句即可。

1
2
3
$ gitlab-runner install

$ gitlab-runner start

之后就可以提交代码测试了,如果顺利runner会执行,并且通知gitlab执行结果,可以在gitlab中查看执行结果。

总结

本文写了一下思想和简要的步骤,也是给自己记一个笔记。自动发布系列我会连载。

如果疏漏欢迎指出,同时欢迎提供新观点,这也是写作的初衷之一。

推荐文章