少湖说 | 科技自媒体

互联网,科技,数码,鸿蒙

2020 更新

微信出了 miniprogram-ci ,可以通过命令行调用,故而改用改方案, 见 [GitLab-CI微信小程序进行持续集成和持续部署2]

问题缘由

在微信小程序开发中,先要在本地使用微信开发者工具进行调试,如果需要在线测试,则需要将编译好的代码上传。
目前,只能通过微信开发者工具手动点击上传,而该过程无法与持续集成/持续部署结合在一起,本文就是为了解决能够实现自动化和持续部署的难题

实现原理

微信开发者工具,提供了HTTP调用方式,其中就包括上传和自动化测试的命令,我们可以通过脚本实现自动化集成

步骤

安装并配置 GitLab Runner

这部分文档在 Install GitLab Runner on macOS

安装

首先需要在本机上安装 GitLab Runner, 由于微信开发者工具只提供了 mac 和 windows 版本,所以目前只能在这两种系统上实现持续集成,本文讲述在 mac 的具体实现, windows 上的实现与此类似,只是相关命令和路径需要做些变更

注册 GitLab Runner

1
2
gitlab-runner register

注意,注册时没有sudo, 因为需要使用用户模式来使用,而非系统模式

注册时,将本机添加上了 mac 标签, 运行模式为shell,这样可以在部署时,指定运行环境

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
https://xxxxxx.com/
Please enter the gitlab-ci token for this runner:
xxxxxx
Please enter the gitlab-ci description for this runner:
[xxx.com]: macbook.home
Please enter the gitlab-ci tags for this runner (comma separated):
mac,shell
Whether to run untagged builds [true/false]:
[false]: true
Whether to lock the Runner to current project [true/false]:
[true]: false
Registering runner... succeeded runner=Gd3NhK2t
Please enter the executor: docker-ssh, virtualbox, docker+machine, docker-ssh+machine, docker, parallels, shell, ssh, kubernetes:
shell
Runner registered successfully. Feel free to start it, but if it's running already the config should be automatically reloaded!

运行服务

1
2
3
4
cd ~
gitlab-runner install
gitlab-runner start

编写 .gitlab-ci.yml

在此之前,你需要对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
image: node:alpine

before_script:
- export APP_ENV=testing
- yarn config set registry 'https://registry.npm.taobao.org'
stages:
- build
- deploy

variables:
NPM_CONFIG_CACHE: "/cache/npm"
YARN_CACHE_FOLDER: "/cache/yarn"
DOCKER_DRIVER: overlay2
build-package:
stage: build
dependencies: []
cache:
key: "$CI_COMMIT_REF_NAME"
policy: pull
paths:
- node_modules
script:
- if [ ! -d "node_modules" ]; then
- yarn install --cache-folder /cache/yarn
- fi
- yarn build
- cp deploy/project.config.json ./dist/project.config.json
artifacts:
name: "wxpkg-dlkhgl-$CI_COMMIT_TAG"
untracked: false
paths:
- dist
only:
- tags
tags:
- docker
deploy:
stage: deploy
dependencies:
- build-package
variables:
GIT_STRATEGY: none
before_script: []
script:
# 获取HTTP服务的端口, 该端口是不固定的
# - PORT=`cat ~/Library/Application\ Support/微信web开发者工具/Default/.ide`
# 调用上传的API
# - curl http://127.0.0.1:$PORT/upload\?projectpath\=$PWD/dist\&version\=$CI_COMMIT_TAG\&desc\=audo-deploy
# 以下改用命令行替代旧的 HTTP 调用方式
- /Applications/wechatwebdevtools.app/Contents/MacOS/cli -u $CI_COMMIT_TAG@/$PWD/dist --upload-desc "aoto deploy"
only:
- tags
tags:
- mac

注意,deploy/project.config.json 文件为 project.config.json的副本,但其他的 projectname 不同,这样做是为了解决 已存在相同 AppID 和 projectname 的项目(路径),请修改后重试的问题,这是因为,同一台电脑上,微信开发者工具不能有两个同名的项目

另外注意,在运行自动部署时,微信开发者工具必须打开,且为登录状态

相关文档

起因

前两天收到跨境电商事业部同事发来的一个需求,说有一个表格,里面只有产品ID和其他一些信息,但是没有其他信息,诸如产品中文名和发货地,这些信息需要通过调取API获得。希望我们帮忙导出合并到Excel中

分析及实现

  • 首先需要读取Excel中,每个产品的ID
  • 然后调用产品查询API,该API通过GET+ID参数方式进行查询
  • 查询到信息后,将需要的信息追加到对应行的后面列中

openpyxl

Python 中操作 Excel 的库有许多,例如 xlrd、xlwt、xlsxwriter、openpyxl 等,openpyxl是其中一个,该库主要有几个特点:支持xlsx,支持对现有文档读写,被Python-Excel优先推荐。
几经对比调研,最终选择 openpyxl。

使用方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 打开excel
wb = load_workbook('files/file.xlsx')
# 拿到打开的sheet
sheet = wb.active
for index in range(0, sheet.max_row):
# load_data 通过requests调用API方法,拿到name和ship_from
name, ship_from = load_data(sheet['A' + str(index + 1)].value)
# 产品中文名称
sheet['D' + str(index + 1)] = name
# 发货地信息
sheet['E' + str(index + 1)] = ship_from
print("同步第" + str(index + 1) + "行")
# 将数据保存到另外一表格中,注意也可以保存到原来表格中
wb.save("files/file-export.xlsx")

在上述代码中,首先加载原始文件files/file.xlsx,然后对默认sheet进行行遍历,每一行第一列An代表产品ID,
load_data方法通过调用API, 查询到该产品的中文名称和发货地,然后再写入后面的列中,如Dn和En

最后全部遍历完后,再保存表格,这样整个需求就实现了

PHP运行环境镜像构建

PHP7中访问SqlServer需要安装sqlsrv 和 pdo_sqlsrv,在此之前需要安装一此必备依赖,如msodbcsql 和 unixodbc-dev,由于SqlServer暂时不支持alpine,所以选择jessie,尽量使镜像保持最小,构建脚本如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
FROM php:7.1-fpm-jessie

ENV ACCEPT_EULA=Y

# Microsoft SQL Server Prerequisites
RUN apt-get update \
&& curl https://packages.microsoft.com/keys/microsoft.asc | apt-key add - \
&& curl https://packages.microsoft.com/config/debian/8/prod.list \
> /etc/apt/sources.list.d/mssql-release.list \
&& apt-get install -y --no-install-recommends \
locales \
apt-transport-https \
&& echo "en_US.UTF-8 UTF-8" > /etc/locale.gen \
&& locale-gen \
&& apt-get update \
&& apt-get -y --no-install-recommends install msodbcsql unixodbc-dev

RUN docker-php-ext-install mbstring \
&& pecl install sqlsrv pdo_sqlsrv \
&& docker-php-ext-enable sqlsrv pdo_sqlsrv

启动本地开发需要的SqlServer服务

由于微软官方提供的SqlServer镜像,无法通过环境变量配置的方便创建数据库,故选择mcmoe/mssqldocker镜像,

使用docker-compose配置方式如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: '3.2'

services:
db:
build: .
image: mcmoe/mssqldocker
environment:
ACCEPT_EULA: Y
SA_PASSWORD: 2astazeY
MSSQL_DB: dev
MSSQL_USER: Kobeissi
MSSQL_PASSWORD: 7ellowEl7akey
ports:
- "1433:1433"
container_name: mssqldev

需要注意的是,MSSQL密码(即上面的SA_PASSWORD和MSSQL_PASSWORD)必须至少8个字符长,包含大写,小写和数字,否则数据库会创建失败

连接访问数据库

在程序中配置数据库的地方,配置DSN如下

1
2
sqlsrv:Server=mssql;Database=dev

sqlsrv 为驱动名称

注:如果是使用Yii2框架,可以使用我构建好的镜像:zacksleo/php:7.1-fpm-mssql

需求

团队使用React开发了一套前端页面, 为了方便协作和部署, 使用 EsLint 进行代码格式审查, 同时进行持续集成和部署, 提高开发效率

配置

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
116
117
118
119
120
121
122
123
image: zacksleo/node

before_script:
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" > ~/deploy.key
- chmod 0600 ~/deploy.key
- ssh-add ~/deploy.key
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
- export APP_ENV=testing
- yarn config set registry 'https://registry.npm.taobao.org'
stages:
- prepare
- test
- build
- deploy

variables:
COMPOSER_CACHE_DIR: "/cache/composer"
DOCKER_DRIVER: overlay2
build-cache:
stage: prepare
script:
- yarn install --cache-folder /cache/yarn
cache:
key: "$CI_COMMIT_REF_NAME"
paths:
- node_modules
except:
- docs
- tags
when: manual
eslint:
stage: test
dependencies: []
cache:
key: "$CI_COMMIT_REF_NAME"
policy: pull
paths:
- node_modules
script:
- if [ ! -d "node_modules" ]; then
- yarn install --cache-folder /cache/yarn
- fi
- yarn eslint ./
except:
- docs
- develop
- master
- tags
build-check:
stage: test
dependencies: []
cache:
key: "$CI_COMMIT_REF_NAME"
policy: pull
paths:
- node_modules
script:
- if [ ! -d "node_modules" ]; then
- yarn install --cache-folder /cache/yarn
- fi
- yarn build
except:
- docs
- develop
- master
- tags
build-package:
stage: test
script:
- if [ ! -d "node_modules" ]; then
- yarn install --cache-folder /cache/yarn
- fi
- if [ $CI_COMMIT_TAG ];then
- cp deploy/production/.env .env
- fi
- yarn build
dependencies: []
cache:
key: "$CI_COMMIT_REF_NAME"
policy: pull
paths:
- node_modules
artifacts:
name: "build"
untracked: false
expire_in: 60 mins
paths:
- build
except:
- docs
only:
- develop
- master
- tags
production-image:
stage: build
image: docker:latest
dependencies:
- build-package
before_script: []
script:
- docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
- docker rmi $CI_REGISTRY_IMAGE:$CI_COMMIT_TAG
only:
- tags
production-server:
stage: deploy
dependencies: []
cache: {}
script:
- cd deploy/production
- rsync -rtvhze ssh . root@$DEPLOY_SERVER:/data/$CI_PROJECT_NAME --stats
- ssh root@$DEPLOY_SERVER "docker login -u gitlab-ci-token -p $CI_JOB_TOKEN $CI_REGISTRY"
- ssh root@$DEPLOY_SERVER "export COMPOSE_HTTP_TIMEOUT=120 && export DOCKER_CLIENT_TIMEOUT=120 && echo -e '\nTAG=$CI_COMMIT_TAG' >> .env && cd /data/$CI_PROJECT_NAME && docker-compose pull web && docker-compose stop && docker-compose rm -f && docker-compose up -d --build"
only:
- tags
environment:
name: staging
url: https://xxx.com

说明

首先使用EsLint进行代码格式检查, 每次合并到主干分支, 进行构建检查, 每次添加Tags, 构建Docker镜像,并进行部署

配置

在项目根目录,新建.styleci.yml 配置文件,并编写配置内容:

1
2
preset: psr2

查看

打开https://styleci.io/,使用Gitlab账号登录,找到对应的项目,点击右侧的 ENABLE STYLECI 启用按钮,即可使用,

每次提交代码,都会看到检测结果

提示

如果没有找到自己的项目,打开 https://styleci.io/account#repos 点击 Sync With GitHub 同步,就会看到

概述

公司的GitLab中,有一个存放所有技术文档的Wiki仓库,按照目录分门别类,包括API文档,编码规范,技术专题文档等,通过与Gollum进行持续部署.

然而在GitLab中,每个项目都有自己的Wiki库, 所以在将项目文档合并更新到总Wiki仓库时,同步更新比较麻烦,通过充分使用GitLab的持续集成功能, 将项目Wiki与Wiki仓库集成, 从而实现了Wiki的自动部署,

同步时,自动同步的提交信息和提交人信息

步骤

配置SSH

  • GitLab中在使用SSH的时候, 会生成公钥和私钥对

  • 将公钥添加到gitlab上, 以便于该用于可以拉取代码

  • CI/CD Piplines中设置 Secret Variables, 这里名为 SSH_PRIVATE_KEY

SSH_PRIVATE_KEY 值为私钥.

编写 .gitlab-ci.yml 文件, 注入私钥, 通过ssh执行远程命令

创建一个分支, 如docs, 在该分支中添加 gitlab-ci.yml文件, 实现wiki自动提交, 内容形如以下内容:

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

image: zacksleo/docker-composer:develop

before_script:
- eval $(ssh-agent -s)
- echo "$SSH_PRIVATE_KEY" > deploy.key
- chmod 0600 deploy.key
- ssh-add deploy.key
- rm -f deploy.key
- mkdir -p ~/.ssh
- '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'

build-docs:
stage: deploy
variables:
GIT_STRATEGY: none
dependencies: []
script:
# 定义变量: 项目Wiki的Git地址,项目(目录)别名
- export WIKI_REPO=git@domain.com:project.wiki.git && export PROJECT_NAME=$CI_PROJECT_NAME
# 创建临时目录, 用于存放和合并git文档
- mkdir ~/tmp && cd ~/tmp
# 克隆项目wiki
- git --git-dir=~/tmp/$PROJECT_NAME.wiki.git clone --depth=1 $WIKI_REPO $PROJECT_NAME
# 删除.git 只保留纯文档, 获取最近的提交日志,用户邮箱和名称
- cd $PROJECT_NAME && export GIT_LOG=`git log -1 --pretty=%B` && export GIT_EMAIL=`git log -1 --pretty=%ae` && export GIT_USERNAME=`git log -1 --pretty=%an` && rm -rf .git && cd ..
# 注册Git账号
- git config --global user.email $GIT_EMAIL && git config --global user.name $GIT_USERNAME
# 克隆联络Wiki
- git clone git@domain.com:orgs/wiki.git
# 删除旧wiki, 增加新wiki
- rm -rf wiki/api/$PROJECT_NAME && mv -f $PROJECT_NAME wiki/api
# 增加提交日志并提交
- cd wiki && git add . && git commit -m "$PROJECT_NAME:$GIT_LOG" && git push origin master
# 删除临时目录
- rm -rf ~/tmp
only:
- docs

其中, 将WIKI_REPO后面的git@domain.com:project.wiki.git替换为项目wiki的git地址,
$CI_PROJECT_NAME替换为项目英文别名(如不改则使用当前GitLab的项目名), 用于在文档中心的api下面创建相关目录。
其他地方不需要修改。

注意: 项目wiki的git地址与项目的git地址不相同, 请在Wiki右侧中的Clone repository 找到

创建 Triggers Token

打开项目的 CI/CD Pipelines 选项, 找到 Triggers, 点击添加一个Token, 并从下方的 Use webhook 段落找到触发URL, 如

https://domain.com/api/v4/projects/74/ref/REF_NAME/trigger/pipeline?token=TOKEN

将TOKEN替换为上述Triggers中获取的Token, 将 REF_NAME 替换分分支名称 docs, 得到最终URL

配置 Webhooks

打开项目的 integrations 选项, 在URL中, 填写上一步中拿到的URL

相关文档

  • [[GitLab-CI使用Docker进行持续部署]]
  • [[使用Git和Gollum搭建Wiki系统]]

背景

在GitLab-CI中,使用artifacts可以确保所需要传递的文件可靠性,但由于生成的artifacts存在的GitLab上,每次需要远程下载,因此速度相对较慢。
所以,在一些对依赖的准确性要求不高的地方,可以考虑使用cache

cache 简介

cache 顾名思义为缓存,不同的任务之前,缓存可以进行共享。根据配置中的声明,在需要缓存时,GitLab-CI会自动下载缓存,以供当前任务使用。

cache一旦命中,意味着这部分文件不需要重新生成(编译,下载或构建),这样一来,便省去了不少功夫,从而加速了构建过程。

使用

生成cache

1
2
3
4
5
6
7
8
9
10
11
  
build-package:
stage: prepare
script:
- composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest
- composer dump-autoload --optimize
cache:
key: "$CI_COMMIT_REF_NAME"
paths:
- vendor

如上,在build-package任务中,声明了cache,其目录为vendor, 当script执行完之后,vendor目录会生成,该任务最后,cache会自动生成(push)

使用cache

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

phpcs:
stage: testing
cache:
key: "$CI_COMMIT_REF_NAME"
policy: pull
paths:
- vendor
script:
- if [ ! -d "vendor" ]; then
- composer install --prefer-dist --optimize-autoloader -n --no-interaction -v --no-suggest && composer dump-autoload --optimize
- fi
- php vendor/bin/phpcs --config-set ignore_warnings_on_exit 1
- php vendor/bin/phpcs --standard=PSR2 -w --colors ./
except:
- docs

如上,该过程定义了所要使用的cache, 由于cache并不保证每次都命中(即拿到的cache可能为空),周时在script处进行判断,如果cache为空时,重新生成所需文件

对比

以doctor-online为例子,在未使用cache之前 ,使用的是artifacts, 每次构建时间在7分钟左右,

使用cache后,构建时间缩短到了1分钟

参考文档

引子

最近接触了一个抽奖的项目,由于用户量比较大,而且第三方提供的认证接口并发量有限,为了保证服务的高可用性,所以对高并限制发有一定的要求。经过一系列研究和讨论,做出了以下一些优化方案。

需求分析

  • 根据用户量和日活情况,估算出并发值在100左右,所以该项目的并发量就当在100上以,初期目标定为600-800

  • 特定页面的并发量不超过300,为了保证不对第三方服务造成访问压力,特将并发控制在150以内

  • 由于奖品数量有限,故得奖时,需要进行并发写入控制,防止奖品超发

实施步骤

前端方面

减少客户端访问次数。

  • 使用CDN对网站的静态资源进行优化,可以答复静态请求次数。

  • 抽奖结果一次性生成。

每个用户有有一次抽奖机会,但只能有一次中奖,其他两次随机弹出推荐产品。所以有一次抽奖中,只需要访问一次服务器的抽奖接口。

  • 使用本地缓存。

将抽奖次数,是否中奖等信息记录在本地,避免超次抽奖和多余的服务器请求。例如,一旦该用户中过将,就不需要再访问服务器抽奖接口。

服务端优化

使用缓存

  • 使用服务端缓存。

将页面和相关数据查询进行缓存,减少数据库访问次数。

部分业务逻辑异步处理

对于不需要实时处理的业务逻辑,压入队列,实现异步处理。例如优惠券的发放。

Nginx 优化

  • 提高 Nginx 处理性能

使用 worker_processesworker_cpu_affinityworker_rlimit_nofileworker_connectionsopen_file_cache等命令,提高nginx的处理性能。

  • Nginx 并发控制。

先看实例,如下:

1
2
3
4
5
6
limit_req_zone $binary_remote_addr zone=req_ip:10m rate=40r/s; // #每个IP平均处理的请求频率为每秒40次
limit_conn_zone $binary_remote_addr zone=conn_ip:10m;
limit_conn_zone $server_name zone=conn_server:10m;
limit_conn conn_ip 5; // #限制某个IP来源的连接并发数,此处为5个
limit_conn conn_server 600; //#限制某个虚拟服务器的总连接数,此处为600个
limit_req zone=req_ip burst=5; //小为5的缓冲区, 当有大量请求过来时,超过了访问频次限制的请求可以先放到这个缓冲区内

在这里,限制了每个IP的请求频率,限制了同一IP的并发连接数,限制了服务器的总连接数

  • 使用 Docker 实现负载均衡

配置 nginx, 使用负载均衡

1
2
3
4
5
6
7
upstream icontact_pool {
server web:9000 weight=5 max_fails=3 fail_timeout=10s;
server web2:9000 weight=5 max_fails=3 fail_timeout=10s;
server web3:9000 weight=5 max_fails=3 fail_timeout=10s;
...
}

如上,通过 Docker 启动多个处理请求的服务容器,在 nginx 中配置每个服务的地址,权重等信息,扩大请求的处理能力

  • 其他服务器环境优化

例如,增加服务器配置(CPU,内存,带宽),如果是PHP, 开启 opcache, 并使用较新版本(php7+), 各种依赖尽量使用最新版本。

1
2
3
4
zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1

参考资料

问题

按照以往的做法,你会使用hexo来生成博客的静态文件,并通过git提交到github上,以此来写作和发布文章。

然而,经过一段时间,你会发现,这种写作方式存在几个问题:

  • 文章源和相关编译、部署程序都存储在本地,如果在其他设备上写作,没有同步措施。这样书写多有不便。
  • 文章源没有备份,也没有充分使用Git来管理。
  • 每次书写完文章,需要手动编译和部署。

鉴于以上几个问题,结合Travis-CI的使用经验,我决定对往常的写作方式进行改进:

步骤

新建分支

除了原来博客中的master分支, 再新建两个分支:docs分支用于存放文章源:hexo分支用于存放一些配置文件,我们将在该分支上进行持续部署。

docs 分支

该分支下存放文章源,各篇均以markdow格式书写。除此之外,有 .travis.yml 配置文件和一个触发部署的脚本 deploy.sh

每当有文章提交上来,就会自动触发一次构建,其内容是通过调用Travis-CI的API,自动执行一次 hexo 分支上的自动构建。

hexo 分支

该分支存放一些hexo的配置文件,当构建被触发时,会自动拉取docs中的文章内容,安装一个material皮肤,并进行hexo的自动网站编译。
最后编译完的静态Html,强制推送到master分支,从而博客自动更新。

简介

Code Climate 是一个代码测试工具, 它可以帮助你进行代码冗余检测、质量评估,同时支持多种语言,如PHP, Ruby, JavaScript, CSS, Golang, Python 等。

使用

配置GitLab Runner

1
2
3
4
5
6
7
8
9
10
11
[[runners]]
....
executor = "docker"
[runners.docker]
tls_verify = false
image = "docker:latest"
privileged = true
disable_cache = false
cache_dir = "cache"
volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/tmp/builds:/builds"]
shm_size = 0

注意, 需要增加一个 /tmp/builds:/builds , 这里用于映射放代码。否则根据官方文档中的描述,无法正常实现

为了能使用宿主机的docker 缓存, 加快构建速度, 这里使用 sock 绑定的方式使用docker, 不使用 docker in docker

配置 .gitlab-ci.yml 文件

1
2
3
4
5
6
7
codeclimate:
image: docker:latest
script:
- docker pull codeclimate/codeclimate
- VOLUME_PATH=/tmp/builds"$(echo $PWD | sed 's|^/[^/]*||')"
- docker run -v /tmp/cc:/tmp/cc -v $VOLUME_PATH:/code -v /var/run/docker.sock:/var/run/docker.sock codeclimate/codeclimate validate-config
- docker run --env CODECLIMATE_CODE="$VOLUME_PATH" -v /tmp/cc:/tmp/cc -v $VOLUME_PATH:/code -v /var/run/docker.sock:/var/run/docker.sock codeclimate/codeclimate analyze -f text

配置 .codeclimate.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
engines:
duplication:
enabled: true
config:
languages:
- javascript
- php
csslint:
enabled: true
eslint:
enabled: true
fixme:
enabled: true
phpmd:
enabled: true
ratings:
paths:
- "**.js"
- "**.css"
- "**.php"
exclude_paths:
- tests/
- vendor/

相关配置请参考官方文档

参考资料

0%