Use Gitlab CI

为何使用 CI/CD

写了一个跨平台桌面应用项目,其使用 Elecron 作为框架,需要在不同的桌面端(mac,win,linux)进行测试+打包工作,手动方式很繁琐,我们希望有一套 CI/CD 能够完成  自动化测试打包及部署。

  • 如果使用的是 Gitlab 作为版本控制工具,对应的使用Gitlab CI作为解决方案。
  • 如果使用 Github 作为版本控制工具,则可以使用Travis CI(支持 Linux + OSX 平台,Windows 支持也将会马上发布)和AppVeyor(支持 Windows + Linux 平台)

我们这边以Gitlab CI为例。

1. 配置 Gitlab Runner

Gitlab Runner.gitlab-ci.yml脚本的运行器,Gitlab Runner是基于 Gitlab-CI 的 API 进行构建的相互隔离的机器(或虚拟机)。GitLab Runner 不需要和 Gitlab 安装在同一台机器上,但是考虑到 GitLab Runner 的资源消耗问题和安全问题,也不建议这两者安装在同一台机器上。

Gitlab Runner分为两种,Shared runnersSpecific runners
Specific runners只能被指定的项目使用,Shared runners则可以运行所有开启 Allow shared runners选项的项目。

关于如何安装Gitlab Runner,这里就不细说了,官方文档 肯定是最佳选择。

这里我们配置了 2 台Specific Runner,一台 Windows 平台下,一台 Linux 平台下,如图所示

顺便说说配置时踩到的坑:

在配置玩 Runner 后,gitlab ui 一直显示这个 Runner 的警告,不是绿色的 而是感叹号 ⚠️

后来发现在执行完gitlab-runner start后,还要执行gitlab-runner run才算是真正的跑起来。。。

我们可以查看一下Linux Runner的配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
sudo vi /etc/gitlab-runner/config.toml

concurrent = 1
check_interval = 0

[session_server]
session_timeout = 1800

[[runners]]
name = "WH46-Linux-Runner"
url = "https://xxxxxxxx.com/"
token = "xxxxxxxx"
executor = "docker"
[runners.docker]
tls_verify = false
image = "python:3.6.6-slim"
privileged = false
disable_cache = false
volumes = ["/root/build_cache:/cache:rw"]
shm_size = 0
pull_policy = "if-not-present"
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
  • 这里我们选择docker作为 Runnerexecutor,当然也可以选择shell
  • 如果想在 docker 的宿主机上保存 cache,可以配置volumes = ["/root/build_cache:/cache:rw"],将宿主机的/root/build_cache目录映射到 docker 的/cache目录,并且可读可写。
  • 这里拉取 docker 镜像的策略是pull_policy = "if-not-present",当本地镜像不存在时,才拉取远程的镜像(默认配置是直接从远程拉取)

下面是Windows Runner的配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
concurrent = 1
check_interval = 0

[session_server]
session_timeout = 1800

[[runners]]
name = "WH44-WIN-Runner"
url = "https://xxxxxxx.com/"
token = "xxxxxxxx"
executor = "shell"
[runners.cache]
[runners.cache.s3]
[runners.cache.gcs]
  • 这里我们选择shell作为 Runnerexecutor。(因为 docker 没有 windows 的镜像,而我们需要在 windows 环境下打包)

2. 配置 .gitlab-ci.yml

只要在项目仓库的根目录添加.gitlab-ci.yml文件,并且配置了Runner(运行器),那么每一次合并请求(MR)或者push 或者打tag 都会触发CI pipeline。

以下是一个例子,更多的配置可以参考 gitlab ci 的官方文档

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
image: python:3.6.6-custom
stages:
- test
- report
- deploy

variables:
PIP_CACHE_DIR: "$CI_PROJECT_DIR/pip-cache"

cache:
key: "$CI_PROJECT_ID"
paths:
- $CI_PROJECT_DIR/pip-cache
- $CI_PROJECT_DIR/node_modules

before_script:
# - apt-get update && apt-get install -y --no-install-recommends gcc python3-dev libssl-dev
# - apt-get install --reinstall -y build-essential
- python --version
- pip install -r zipoc/requirements.txt -i https://mirrors.aliyun.com/pypi/simple

test:
stage: test
tags:
- linux
script:
- pip list
# - python -m unittest

coverage:
stage: report
tags:
- linux
coverage: '/TOTAL\s+\d+\s+\d+\s+(\d+%)/'
script:
- pip install coverage
# - coverage run -m unittest
- coverage report

windows package:
stage: deploy
tags:
- win
before_script:
- pwd
- virtualenv.exe --python "C:\\Users\\app\\AppData\\Local\\Programs\\Python\\Python36\\python.exe" env
- call env\Scripts\activate
- call pip install -r zipoc/requirements.txt
script:
- pyinstaller
- npm run build:win32
artifacts:
paths:
- build/zipoc-win32-x64/
expire_in: 7d
only:
- tags
except:
- branches

问题: windows runner 不运行

运行完before_script后面的script就跳过不运行了,后来发现是CMD的坑。

在 windows 上使用 Runner 时,默认 shell 是CMD,有太多 80 年代的MS-DOS遗留问题需要踩,
解决办法是在命令前加上call
或者使用powershell作为 Runner 的shell

1
2
3
4
5
6
7
8
9
10
11
12
before_script:
- call npm install --silent

stages:
- test

lint:
stage: test
tags:
- javascript
script:
- call eslint */**
如果我的文章对你有很大帮助 那么不妨?
0%