三方仓库如何实现Zadig流水线自动触发-编程学习网

最近因为公司的产研调整，决定将代码仓库从本地的 Gitlab 迁移到云效的 Codeup，不是 Gitlab 不够好，而是 Codeup 在度量、安全等方面比原生的 Gitlab 要好，再则公司的产研管理也迁移到了云效，也为了统一化管理。

有同学可能会问，都用云效了，为什么不直接用它的 AppStack，还要用 Zadig？

AppStack 还处于发展阶段，还有以下问题不适合我们现阶段的需求：

AppStack 不支持管理私有云 Kubernetes 集群（没有公网入口）。
AppStack 不支持 Helm 类应用，改造工作比较大。

再则，我也是 Zadig 开源产品的忠实粉丝~~！

但是，Zadig 对非标准的代码仓库的支持力度有限，比如：

非标准代码仓库不支持列出仓库列表，需要自己手动填写
非标准代码仓库创建的流水线原生不支持 Webhook 触发

经过综合考虑，手动填写代码仓库信息以及不支持 Webhook 并不影响整体的使用，只是会影响部分项目的工作效率。

但是，为了最小程度上影响原有的产研节奏，我还是准备自己实现三方仓库的 Webhook 触发 Zadig 流水线。因为本身也不复杂。

整体思路

实现不复杂，也就是接收到 webhook 触发动作，解析内容，根据需要触发相应的流水线接口。截至目前（v1.17.0）zadig 的触发流水线接口已经可以正常使用了。

开始搬砖

封装 Zadig API

首先封装一下 Zadig 的 API。为了方便使用，之前的弄了一个 go-zadig 项目（https://github.com/joker-bai/go-zadig），这两天将其做了更新，支持最新的 1.17.0 版本的 API。

主要增加了以下内容：

// 执行工作流
type ExecWorkflowTaskOptions struct {
 WorkflowName string        `json:"workflow_name"`
 ProjectName  string        `json:"project_name"`
 Input        WorkflowInput `json:"input"`
}

type WorkflowInput struct {
 TargetEnv string         `json:"target_env,omitempty"`
 Build     ExecBuildArgs  `json:"build"`
 Deploy    ExecDeployArgs `json:"deploy"`
}

type ExecBuildArgs struct {
 Enabled     bool               `json:"enabled"`
 ServiceList []BuildServiceInfo `json:"service_list"`
}

type BuildServiceInfo struct {
 ServiceModule string           `json:"service_module"`
 ServiceName   string           `json:"service_name"`
 RepoInfo      []RepositoryInfo `json:"repo_info"`
 Inputs        []UserInput      `json:"inputs"`
}

type RepositoryInfo struct {
 CodehostName  string `json:"codehost_name"`
 RepoNamespace string `json:"repo_namespace"`
 RepoName      string `json:"repo_name"`
 Branch        string `json:"branch"`
 PR            int    `json:"pr"`
}

type UserInput struct {
 Key   string `json:"key"`
 Value string `json:"value"`
}

type ExecDeployArgs struct {
 Enabled     bool                `json:"enabled"`
 Source      string              `json:"source"`
 ServiceList []DeployServiceInfo `json:"service_list"`
}

type DeployServiceInfo struct {
 ServiceModule string `json:"service_module"`
 ServiceName   string `json:"service_name"`
 Image         string `json:"image"`
}

type ExecWorkflowTaskResponse struct {
 ProjectName  string `json:"project_name,omitempty"`
 WorkflowName string `json:"workflow_name,omitempty"`
 TaskID       int64  `json:"task_id,omitempty"`
}

func (w *WorkflowService) ExecWorkflowTask(opt *ExecWorkflowTaskOptions, options ...RequestOptionFunc) (*ExecWorkflowTaskResponse, *Response, error) {
 path := "openapi/workflows/product/task"
 req, err := w.client.NewRequest(http.MethodPost, path, opt, options)
 if err != nil {
  return nil, nil, err
 }

 task := new(ExecWorkflowTaskResponse)
 resp, err := w.client.Do(req, &task)
 if err != nil {
  return nil, resp, err
 }

 return task, resp, err
}

这部分是执行标准工作流的接口。自定义工作流之前已经实现了，并没有什么变化。

开发 Http Server

由于 Zadig 原生不支持三方仓库的 Webhook，要实现不外乎两种：

自己修改 Zadig 源码，实现这部分功能。
找一个中间商，由它来协调。

修改源码的好处是可以不需要再单独对数据这块做太多处理，直接用现成的。但我选择了后者，主要是因为菜，源码改起来费劲。

我使用的是 Uber 的 fx 框架。其实用什么框架不重要，本身的逻辑就很简单，我只是选了一个用起来比较简单和顺手的。

（1）定义数据结构

package entity

type ZadigWorkflowTask struct {
 ID            int    `json:"id"`
 ProjectName   string `json:"project_name"`   // 项目名
 ServiceModule string `json:"service_module"` // 服务组件名称
 ServiceName   string `json:"service_name"`   // 服务名
 CodehostName  string `json:"codehost_name"`  // 代码源别名
 RepoNamespace string `json:"repo_namespace"` // 仓库组名
 RepoName      string `json:"repo_name"`      // 仓库名
 WorkflowType  string `json:"workflow_type"`  // 工作流类型: product/custom
 JobName       string `json:"job_name"`       // 任务名 workflow_type为custom生效
 JobType       string `json:"job_type"`       // 任务类型 workflow_type为custom生效
 Registry      string `json:"registry"`       // 镜像仓库  workflow_type为custom生效
}

func (z *ZadigWorkflowTask) Table() string {
 return "zadig_workflow_task"
}

type ZadigWorkflowName struct {
 ID           int    `json:"id"`
 WorkflowName string `json:"workflow_name"` // workflow名
 Branch       string `json:"branch"`        // 分支
 ProjectName  string `json:"project_name"`  // 项目名
 TargetEnv    string `json:"target_env"`    // 目标环境
}

func (z *ZadigWorkflowName) Table() string {
 return "zadig_workflow_name"
}

我定义的比较简单，命名也比较随意。主要的字段就是 Zadig API 需要的字段，其他不需要的就没写了。

（2）实现 Zadig 触发标准和非标准流水线

package zadig

import (
 "github.com/joker-bai/go-zadig"
 "joker-bai/go-webhook/config"
)

type Zadig struct {
 client *zadig.Client
}

func NewZadig(cfg *config.Config) *Zadig {
 client, err := zadig.NewClient(cfg.ZadigConfig.Token, zadig.WithBaseURL(cfg.ZadigConfig.URL))
 if err != nil {
  panic(err)
 }
 return &Zadig{client: client}
}

// ExecProductWorkflowTask 执行标准工作流
func (z *Zadig) ExecProductWorkflowTask(workflowName, projectName, targetEnv, serviceModule, serviceName, codehostName, repoNamespace, repoName, branch string) error {
 _, _, err := z.client.Workflow.ExecWorkflowTask(&zadig.ExecWorkflowTaskOptions{
  WorkflowName: workflowName,
  ProjectName:  projectName,
  Input: zadig.WorkflowInput{
   TargetEnv: targetEnv,
   Build: zadig.ExecBuildArgs{
    Enabled: true,
    ServiceList: []zadig.BuildServiceInfo{
     {
      ServiceModule: serviceModule,
      ServiceName:   serviceName,
      RepoInfo: []zadig.RepositoryInfo{
       {
        CodehostName:  codehostName,
        RepoNamespace: repoNamespace,
        RepoName:      repoName,
        Branch:        branch,
       },
      },
     },
    },
   },
   Deploy: zadig.ExecDeployArgs{
    Enabled: true,
    Source:  "zadig",
   },
  },
 })
 return err
}

// ExecCustomWorkflowTask 执行自定义工作流
func (z *Zadig) ExecCustomWorkflowTask(projectName, workflowName, jobName, jobType, registry, serviceModule, serviceName, codehostName, repoNamespace, repoName, branch string) error {
 _, _, err := z.client.CustomWorkflow.CreateCustomWorkflowTask(&zadig.CreateCustomWorkflowTask{
  ProjectName:  projectName,
  WorkflowName: workflowName,
  Inputs: []zadig.CreateCustomWorkflowTaskInput{
   {
    JobName: jobName,
    JobType: jobType,
    Parameters: zadig.CreateCustomWorkflowTaskParameters{
     Register: registry,
     ServiceList: []zadig.ServiceList{
      {
       ServiceModule: serviceModule,
       ServiceName:   serviceName,
       RepoInfo: []zadig.RepoInfo{
        {
         CodehostName:  codehostName,
         RepoNamespace: repoNamespace,
         RepoName:      repoName,
         Branch:        branch,
        },
       },
      },
     },
    },
   },
  },
 })

 return err
}

这里对工作流的 API 进行了取舍，根据实际情况选择需要的字段。

（3）实现 service 方法

package service

import (
 "context"
 "fmt"
 "github.com/sirupsen/logrus"
 "go.uber.org/fx"
 "joker-bai/go-webhook/config"
 "joker-bai/go-webhook/infrastructure/db"
 "joker-bai/go-webhook/internal/domain/entity"
 "joker-bai/go-webhook/pkg/zadig"
)

// 获取并处理Codeup的Webhook

type CodeupWebhookService struct {
 logger *logrus.Logger
 cfg    *config.Config
 db     *db.DataBase
}

var RegCodeupWebhookService = fx.Provide(func(logger *logrus.Logger, cfg *config.Config, db *db.DataBase) *CodeupWebhookService {
 return &CodeupWebhookService{
  logger: logger,
  cfg:    cfg,
  db:     db,
 }
})

// ExecZadigWorkflowTask 触发执行zadig的工作流
func (c *CodeupWebhookService) ExecZadigWorkflowTask(ctx context.Context, repoName, branch string) error {
 client := zadig.NewZadig(c.cfg)

 // 从数据库中获取数据
 dbClient := c.db.Master.WithContext(ctx)
 var workflowTask entity.ZadigWorkflowTask
 workflowTaskRes := dbClient.Model(&workflowTask).Where("repo_name = ?", repoName).First(&workflowTask)
 if workflowTaskRes.Error != nil {
  return workflowTaskRes.Error
 }

 // 从数据库获取项目和工作流信息
 var flowName entity.ZadigWorkflowName
 workflowNameRes := dbClient.Model(&flowName).Where("branch = ? and project_name = ?", repoName, workflowTask.ProjectName).First(&flowName)
 if workflowNameRes.Error != nil {
  return workflowNameRes.Error
 }

 // 判断workflow的类别
 if workflowTask.WorkflowType == "product" {
  return client.ExecProductWorkflowTask(
   flowName.WorkflowName,
   workflowTask.ProjectName,
   flowName.TargetEnv,
   workflowTask.ServiceModule,
   workflowTask.ServiceName,
   workflowTask.CodehostName,
   workflowTask.RepoNamespace,
   workflowTask.RepoName,
   branch,
  )
 } else if workflowTask.WorkflowType == "custom" {
  return client.ExecCustomWorkflowTask(
   workflowTask.ProjectName,
   flowName.WorkflowName,
   workflowTask.JobName,
   workflowTask.JobType,
   workflowTask.Registry,
   workflowTask.ServiceModule,
   workflowTask.ServiceName,
   workflowTask.CodehostName,
   workflowTask.RepoNamespace,
   workflowTask.RepoName,
   branch,
  )
 } else {
  return fmt.Errorf("未匹配workflow类型")
 }
}

这里从数据库获取需要的信息，然后根据不同的工作流类型执行不同的接口。

（4）实现 controller 方法

package application

import (
 "fmt"
 "github.com/gin-gonic/gin"
 "github.com/sirupsen/logrus"
 "go.uber.org/fx"
 "joker-bai/go-webhook/internal/core/base"
 "joker-bai/go-webhook/domain/service"
 "strings"
 "time"
)

var regCodeupWebhookApplication = fx.Provide(NewCodeupWebhookController)

type CodeupWebhookController struct {
 logger  *logrus.Logger
 service *service.CodeupWebhookService
}
type CodeupWebhook struct {
 After             string     `json:"after"`
 AliyunPk          string     `json:"aliyun_pk"`
 Before            string     `json:"before"`
 CheckoutSha       string     `json:"checkout_sha"`
 Commits           []Commits  `json:"commits"`
 ObjectKind        string     `json:"object_kind"`
 ProjectID         int        `json:"project_id"`
 Ref               string     `json:"ref"`
 Repository        Repository `json:"repository"`
 TotalCommitsCount int        `json:"total_commits_count"`
 UserEmail         string     `json:"user_email"`
 UserExternUID     string     `json:"user_extern_uid"`
 UserID            int        `json:"user_id"`
 UserName          string     `json:"user_name"`
}
type Author struct {
 Email string `json:"email"`
 Name  string `json:"name"`
}
type Commits struct {
 Author    Author    `json:"author"`
 ID        string    `json:"id"`
 Message   string    `json:"message"`
 Timestamp time.Time `json:"timestamp"`
 URL       string    `json:"url"`
}
type Repository struct {
 Description         string `json:"description"`
 GitHTTPURL          string `json:"git_http_url"`
 GitSecondaryHTTPURL string `json:"git_secondary_http_url"`
 GitSecondarySSHURL  string `json:"git_secondary_ssh_url"`
 GitSSHURL           string `json:"git_ssh_url"`
 Homepage            string `json:"homepage"`
 Name                string `json:"name"`
 URL                 string `json:"url"`
 VisibilityLevel     int    `json:"visibility_level"`
}

func NewCodeupWebhookController(logger *logrus.Logger, service *service.CodeupWebhookService) *CodeupWebhookController {
 return &CodeupWebhookController{
  logger:  logger,
  service: service,
 }
}

// DoCodeupWebhook 获取Codeup 代码webhook的Body
func (c *CodeupWebhookController) DoCodeupWebhook(ctx *gin.Context) {
 output := base.NewResponse(ctx)
 var param CodeupWebhook
 err := ctx.ShouldBindJSON(¶m)
 if err != nil {
  output.Error(10000, err.Error())
  return
 }

 // 获取repo_name,repo_namespace,branch
 repoName := param.Repository.Name
 branch := strings.Split(param.Ref, "/")[2]

 if err := c.service.ExecZadigWorkflowTask(ctx, repoName, branch); err != nil {
  c.logger.Error(err.Error())
  output.Error(502, "执行workflow失败")
 }

 output.Success(gin.H{
  "data": "ok",
 })
}

这部分就更简单了，从 Webhook 中获取数据，然后调 service 去执行即可。

最后就是增加路由了，这部分就不用展示了。

搬砖结束

搬砖完成过后就是对自己开发的 HTTP Server 进行验证了。

整个思路和开发的工作量都不大，上面的代码还有很多地方需要去调整的，如果有相同需求的可以自己去实现，我仅仅是做了一个 demo。

通过引入中间商的方式来实现自己的需求的优点是比较简单，不需要去看或者兼容其他的代码，只需要实现自己的逻辑，缺点就是数据这一块需要单独去处理，比较麻烦。

文章详情

三方仓库如何实现Zadig流水线自动触发