CI/CD 是持续集成（Continuous Integration）和持续交付/持续部署（Continuous Delivery/Continuous Deployment）的缩写，是一种软件开发和交付的最佳实践。这两个概念通常一起使用，但有些时候它们也会被区分开来：
持续集成 (CI - Continuous Integration): 持续集成是一种开发实践，旨在通过频繁地集成和验证代码，确保团队成员的工作不会破坏整体代码库的稳定性。在 CI 中，开发者将代码频繁地合并到共享的主干（主要分支），每次合并都会触发自动构建、测试和代码静态分析等过程。如果有问题，团队可以尽早发现并纠正。
持续交付 (CD - Continuous Delivery): 持续交付是一种软件开发流程，旨在通过自动化构建、测试和部署的过程，使软件随时都能够交付到生产环境。持续交付的目标是确保代码在通过 CI 流程后可以随时投入生产环境，但在投入生产之前可能需要手动的最终审查和决策。
持续部署 (CD - Continuous Deployment): 持续部署是持续交付的进一步延伸，它的目标是通过自动化流程，将通过 CI 流程的代码自动部署到生产环境，无需人工干预。在持续部署中，合格的代码经过自动测试后，将直接部署到生产环境。
CI/CD 工作流程通常包括自动化测试、构建、部署和监控等环节，以确保软件可以快速、高效地交付到最终用户手中。这对于敏捷开发、DevOps 实践以及快速响应市场需求都是非常关键的。
项目A更新代码之后通过webhook触发项目B的pipeline
在需要被触发的项目的setting里面找到 Pipeline triggers，点击Add trigger 生成 token
当创建了token之后，可以通过API或者是webhook用 token 来触发 pipeline 事件
例如cURL：
curl --request POST \
--form token=<token> \
--form ref=<ref_name> \
"https://gitlab.example.com/api/v4/projects/<project_id>/trigger/pipeline"
CI/CD Job：
trigger_pipeline:
stage: deploy
script:
- 'curl --fail --request POST --form token=$MY_TRIGGER_TOKEN --form ref=main "https://gitlab.example.com/api/v4/projects/123456/trigger/pipeline"'
rules:
- if: $CI_COMMIT_TAG
environment: production
WebHook：Webhook（网络挂钩）是一种用于实时事件通知的机制，它允许一个系统将事件信息发送到另一个系统。Webhook 是在特定事件发生时自动触发的 HTTP POST 请求。通常，Webhook 被用于将实时事件从一个系统推送到另一个系统，从而触发自动化的操作。
https://gitlab.example.com/api/v4/projects/<project_id>/ref/<ref_name>/trigger/pipeline?token=<token>
我们这里使用 WebHook来触发项目B的自动更新事件：在项目A的设置里找到 Webhooks 填入 pipeline trigger 中获得的 url，选择相应的触发事件，下图选择了 Push 操作来触发自动更新错误码文档。
官方文档地址：GitLab官方文档
自动更新文档需要运行代码，这里需要我们首先有一个 runner
GitLab Runner 是 GitLab CI/CD（持续集成/持续交付）系统的一个组件，用于执行构建、测试和部署作业。Runner 负责接收来自 GitLab CI 的作业请求，并在指定的环境中执行这些作业。每个 Runner 都与一个特定项目相关联，并负责处理该项目的 CI/CD 工作。
mac下载 GitLab Runner：
brew install gitlab-runner
注册：这一步需要注意设置了tag后续ci文件里要指定tag
gitlab-runner register
启动：
gitlab-runner install
gitlab-runner start
.gitlab-ci.yml是 GitLab CI/CD 配置文件，用于定义项目的 CI/CD 流程。这个文件应该位于项目的根目录，并包含了构建、测试、部署等阶段的定义。
以下是一个简单示例：
stages:
- build
- test
- deploy
variables:
# 定义全局变量，可以在整个文件中使用
GIT_STRATEGY: clone
TEST_IMAGE: "alpine:latest"
before_script:
# 所有阶段执行前都会执行的脚本
- echo "Before script: Initialize environment"
build_job:
stage: build
script:
- echo "Building the project..."
test_job:
stage: test
script:
- echo "Running tests..."
only:
- master # 只有在 master 分支上触发
deploy_job:
stage: deploy
script:
- echo "Deploying to production..."
only:
- master
上述示例文件定义了三个阶段（
build
、
test
、
deploy
），并定义了一些全局变量。每个阶段下都有一个或多个作业（
job
）的定义，包括作业的名称、阶段、脚本等信息。
before_script
: 定义了在所有阶段执行前都会运行的脚本。
build_job
: 定义了一个构建作业，用于构建项目。
test_job
: 定义了一个测试作业，用于运行测试。通过
only
关键字，指定只有在
master
分支上触发时才执行。
deploy_job
: 定义了一个部署作业，用于将项目部署到生产环境。同样，通过
only
关键字，指定只有在
master
分支上触发时才执行。
自动更新操作：
stages:
- run_main_go
run_main_go:
stage: run_main_go
image: reg.smvm.cn/appbase/golang-build:1.21-alpine3.17
script:
- go mod download -x
- go run main.go
artifacts:
paths:
- "*.md"
tags:
- k8runner
项目A的Push事件都会触发项目B的自动更新文档操作
