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

发布时间:2024年01月15日

一、CI/CD简介

CI/CD 是持续集成(Continuous Integration)和持续交付/持续部署(Continuous Delivery/Continuous Deployment)的缩写,是一种软件开发和交付的最佳实践。这两个概念通常一起使用,但有些时候它们也会被区分开来:

  1. 持续集成 (CI - Continuous Integration):持续集成是一种开发实践,旨在通过频繁地集成和验证代码,确保团队成员的工作不会破坏整体代码库的稳定性。在 CI 中,开发者将代码频繁地合并到共享的主干(主要分支),每次合并都会触发自动构建、测试和代码静态分析等过程。如果有问题,团队可以尽早发现并纠正。

  2. 持续交付 (CD - Continuous Delivery):持续交付是一种软件开发流程,旨在通过自动化构建、测试和部署的过程,使软件随时都能够交付到生产环境。持续交付的目标是确保代码在通过 CI 流程后可以随时投入生产环境,但在投入生产之前可能需要手动的最终审查和决策。

  3. 持续部署 (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

注册:这一步需要注意设置了tag后续ci文件里要指定tag

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

上述示例文件定义了三个阶段(buildtestdeploy),并定义了一些全局变量。每个阶段下都有一个或多个作业(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的自动更新文档操作

文章来源:https://blog.csdn.net/Candy___i/article/details/135595343
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。