GitLab CI 实现项目A更新代码自动触发项目B更新错误码文档

news2024/11/20 2:26:05

一、CI/CD简介

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

1. 创建 pipeline trigger token

在需要被触发的项目的setting里面找到 Pipeline triggers，点击Add trigger 生成 token

2. 触发

当创建了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 操作来触发自动更新错误码文档。

3. 创建和运行 pipeline

官方文档地址：GitLab官方文档

自动更新文档需要运行代码，这里需要我们首先有一个 runner

GitLab Runner 是 GitLab CI/CD（持续集成/持续交付）系统的一个组件，用于执行构建、测试和部署作业。Runner 负责接收来自 GitLab CI 的作业请求，并在指定的环境中执行这些作业。每个 Runner 都与一个特定项目相关联，并负责处理该项目的 CI/CD 工作。

mac下载 GitLab Runner：

brew install gitlab-runner

gitlab-runner register

启动：

gitlab-runner install

gitlab-runner start

4. 编写.gitlab-ci.yml 文件

.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的自动更新文档操作