-- [一、介绍](#1)
-- [二、快速上手](#2)
-- [1、为您的项目添加x-ci.yml文件](#21)
-- [2、正常提交您的项目](#22)
-- [3、CIManager开始工作](#23)
-- [三、CI/CD配置](#3)
-- [四、私有化部署](#4)
-- [1、下载项目](#41)
-- [2、部署至私有仓库](#42)
-- [3、自定义扩展](#43)
-- [4、多语言支持](#44)
-- [五、帮助文档](#5)
-- [六、贡献榜](#6)
-
-## 一、介绍
+## 一、介绍
在微服务下，每一个项目仓库都需要维护独立的```CI/CD```，一旦```CI/CD```有设计升级或变更，所有仓库都需要配合做联动性调整，维护成本极高。
为了解决这个问题，曾经提出过一种方案，详细请见文章 [《多项目下CI管理方案的设计与实现》](https://github.com/WGrape/Blog/issues/249) 。
本项目是基于文章中的```远程管理```方案设计而实现的一个用于高效管理多个项目通用CI的轻量级开源框架，它不但完全开箱即用，而且方便定制化开发与扩展。
-## 二、快速上手
+## 二、快速上手
-> 1、在```CIManager```的早期版本中仅支持```gitlab```项目，但在 [v1.3.0](https://github.com/WGrape/CIManager/releases/tag/v1.3.0) 版本后新增了对```github```项目的支持。
->
-> 2、为了方便您快速应用，可以参考 [apimock-example](https://jihulab.com/WGrape/apimock-example/) 和 [matching](https://github.com/WGrape/matching) 项目是如何在```gitlab```和```github```中使用```CIManager```进行```CI/CD```管理的
+> 您可以参考 [apimock-example](https://jihulab.com/WGrape/apimock-example/) 和 [matching](https://github.com/WGrape/matching) 项目是如何在```gitlab```和```github```中使用的
-### 1、为您的项目添加x-ci.yml文件
+### 1、为您的项目添加ci.yml文件
-> 如果您使用的github项目，需要创建```.github/workflows/.github-ci.yml```配置文件。如果您使用的gitlab项目，需要创建```.gitlab-ci.yml```配置文件。
-
-首先，和单项目下的CI管理方式一样，在您的各个项目下添加一个```.gitlab-ci.yml```或```.github/workflows/.github-ci.yml```配置文件，它的内容如下所示
+首先，和单项目下的CI管理方式一样，在您的各个项目下添加一个```.gitlab-ci.yml```或```.github/workflows/.github-ci.yml```配置文件。在```/template```目录下有定义好配置文件，您可以直接使用。
```yaml
-image: golang:1.17
-
-before_script:
- - echo '====== CIManager Start Running ========='
-
-after_script:
- - echo '====== CIManager Stopped Successfully ========='
-
-stages:
- - CIManager
-
-CIManager:
- stage: CIManager
- script:
- # 注意如果是github项目, 则需要使用 bash start.sh github
- - git clone https://github.com/wgrape/CIManager.git ; cp -an ./CIManager/. ./ ; rm -rf ./CIManager ; bash start.sh gitlab
+cp {CIManager_path}/template/.gitlab-ci.yml {your_project}/.gitlab-ci.yml
```
-### 2、正常提交您的项目
+### 2、正常提交您的项目
添加完之后，如往常一样，正常编写并提交您的项目即可
-### 3、CIManager开始工作
+### 3、CIManager开始工作
当您每次提交项目的时候，在runner机器上都会运行CIManager，它的底层[运行原理](https://github.com/WGrape/Blog/issues/249)如下图所示，详细运行过程可以 [查看这里](https://jihulab.com/WGrape/apimock-example/-/jobs/4354428)
-
-
-## 三、CI/CD配置
-基于低耦合、易扩展、高效率的思想，CIManager框架内部集成了非常丰富的Stage，通过不同Stage的组合构成了一个完整的集成和发布流程。
-
-
+
-那么是如何实现的呢？在 [apimock-example](https://jihulab.com/WGrape/apimock-example/-/blob/main/.gitlab-ci.yml) 项目例子中，会发现定义了大量的```variables```变量，正是这些变量被应用于不同的Stage，才实现了强大丰富的```CI/CD```功能。
+## 三、更多文档
-默认情况下，即使不配置任何变量，也可以正常使用部分功能。如果您想要了解更多```CI/CD```的配置，请查看[使用教程](./doc/Usage.md#1)
+- [1. 使用文档](./doc/USAGE.md)
+- [2. 设计文档](./doc/DESIGN.md)
+- [3. 常见问题](./doc/QA.md)
-## 四、私有化部署
+## 四、私有化部署
-### 1、下载项目
+### 1、下载项目
无需任务复杂安装过程，直接通过Git方式clone到本地即可。
@@ -96,23 +60,17 @@ CIManager:
git clone https://github.com/WGrape/CIManager.git
```
-### 2、部署至私有仓库
+### 2、部署至私有仓库
如果您不需要对```CIManager```框架进行扩展开发，那么直接把它提交至您的私有仓库，并在您各个项目中的```.gitlab-ci.yml```或```.github/workflows/.github-ci.yml```配置文件中的```https://github.com/WGrape/CIManager.git```替换为CIManager在您私有仓库中的地址即可。
-### 3、自定义扩展
-本框架源码轻量简单，如果不满足您的需求，您可以在```CIManager```框架基础上进行自定义扩展的开发。
+### 3、自定义开发
+本框架源码轻量简单，如果不满足您的需求，您可以在```CIManager```框架基础上进行自定义开发，比如新增配置检查、依赖检查等丰富和加强```CI/CD```的流水线功能。具体请参考[设计原理文档](./doc/DESIGN.md)
-当然也可以新增配置检查、依赖检查等加强```CI/CD```的阶段（Stage）操作，直接修改源码即可。具体请参考[设计原理文档](./doc/design.md)
+## 五、贡献
-### 4、多语言支持
-虽然本项目以```golang```语言为例，但是您只需要简单修改源码，即可实现任何语言多项目的CI/CD统一管理。
-
-## 五、问题与解答
-如果在您使用过程中遇到问题，可以查看[使用教程](./doc/Usage.md#1)，或在```ISSUE```中提问。
-
-## 六、贡献与使用榜
-
--为了方便您快速应用，可以参考 apimock-example 项目是如何使用
CIManager的
首先，和单项目下的CI管理方式一样，在您的各个项目下添加一个.gitlab-ci.yml配置文件，它的内容如下所示
首先，和单项目下的CI管理方式一样，在您的各个项目下添加一个```.gitlab-ci.yml```或```.github/workflows/.github-ci.yml```配置文件。在```/template```目录下有定义好配置文件，您可以直接使用。
--image: golang:1.17 - -before_script: - - echo '====== CIManager Start Running =========' - -after_script: - - echo '====== CIManager Stopped Successfully =========' - -stages: - - CIManager - -CIManager: - stage: CIManager - script: - - git clone https://github.com/wgrape/CIManager.git ; cp -an ./CIManager/. ./ ; rm -rf ./CIManager ; bash start.sh+
cp {CIManager_path}/template/.gitlab-ci.yml {your_project}/.gitlab-ci.yml
当您每次提交项目的时候，在runner机器上都会运行CIManager，它的底层运行原理如下图所示，详细运行过程可以查看这里
-
基于低耦合、易扩展、高效率的思想，CIManager框架内部集成了非常丰富的Stage，通过不同Stage的组合构成了一个完整的集成和发布流程。
- -
-
- 那么是如何实现的呢？在apimock-example项目例子中，会发现定义了大量的variables变量，正是这些变量被应用于不同的Stage，才实现了强大丰富的CI/CD功能。
- -默认情况下，即使不配置任何变量，也可以正常使用部分功能。如果您想要了解更多CI/CD配置，请查看文档
+下面是所支持的系统级别的变量
@@ -539,6 +517,7 @@下面是所支持的项目级别的变量
| 项目名称 | 无 | -||
| PROJECT_ID | -否 | -项目的ID | -无 | -
下面是在不同阶段（Stage）所支持的变量
-下面是在不同Job中所支持的变量
+ +| UNIT_TEST_TRIGGER_CMD | +CI_STAGE_BUILD_JOB_PRE_CHECK_CMD | +否 | +预检查的命令 | +无 | +
| CI_STAGE_BUILD_JOB_PRE_INSTALL_CMD | 否 | -触发单元测试的命令 | +预安装的命令 | 无 |
| APIDOC_TRIGGER_CMD | +CI_STAGE_BUILD_JOB_CHECK_CODE_CMD | 否 | -触发生成接口文档的命令 | +代码检查的命令 | 无 |
| APIDOC_FILE | +CI_STAGE_BUILD_JOB_UNIT_TEST_CMD | 否 | -生成的接口文档路径 | -无 | -|
| GITLAB_HOST | -否 | -gitlab私有化部署的域名 | -无 | -||
| GITLAB_API_TOKEN | -否 | -gitlab配置的API Token | +单元测试的命令 | 无 |
| LOCAL_BUILD_TRIGGER_CMD | +CI_STAGE_BUILD_JOB_APIDOC_GEN_CMD | +否 | +生成接口文档时的命令 | +无 | +
| CI_STAGE_BUILD_JOB_LOCAL_BUILD_CMD | 是 | -构建项目的命令 | +项目构建时的命令 | 无 |
| HEALTH_CHECK_TRIGGER_CMD | -是 | -健康检查和检测成功运行的命令 | +CD_STAGE_MONITOR_JOB_SSH_CMD | +否 | +执行SSH部署时的命令 | 无 |
| HEALTH_CHECK_SUCCESS | -是 | -健康检查成功的返回内容 | +CD_STAGE_MONITOR_JOB_PULL_ARTIFACT_CMD | +否 | +使用拉取镜像部署时的命令 | 无 |
下面是所支持的其它变量
+ +| DING_KEYWORD | +CD_STAGE_MONITOR_JOB_API_TEST_CMD | +否 | +执行接口测试的命令 | +无 | +|
| CD_STAGE_MONITOR_JOB_API_TEST_CMD_RES | 否 | -钉钉群通知关键字 | +接口请求成功时的返回内容 | 无 | |
| DING_ACCESS_TOKEN | +CD_STAGE_MONITOR_JOB_HEALTH_CHECK_CMD | 否 | -钉钉群通知的WebHook Token | +执行健康检查的命令 | 无 |
| DING_NOTICE_SWITCH | +CD_STAGE_MONITOR_JOB_HEALTH_CHECK_CMD_RES | 否 | -是否开启钉钉群通知 | +健康检查成功时的返回内容 | 无 |
-