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

430


!! 大家好，我是乔克，一个爱折腾的运维工程，一个睡觉都被自己丑醒的云原生爱好者。

作者：乔克
公众号：运维开发故事
博客：www.jokerbai.com

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

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

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

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

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

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

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

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

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

整体思路

图片
image.png

实现不复杂，也就是接收到 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，要实现不外乎两种：

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

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

!! 我使用的是 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) TableName() 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) TableName() 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(&param)
 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。

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

最后，求关注。如果你还想看更多优质原创文章，欢迎关注我们的公众号「运维开发故事」。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！

你还可以把我的公众号设为「星标」，这样当公众号文章更新时，你会在第一时间收到推送消息，避免错过我的文章更新。


我是 乔克，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！


------本页内容已结束，喜欢请分享------

© 版权声明
THE END
杂谈
喜欢就支持一下吧
点赞0
分享
  • 运维开发故事的头像-运维开发故事
  • 运维开发故事
    1922.9W+17
    由一群志同道合的小伙伴共同维护，有运维也有开发，内容不限于Linux运维，devops工具链，k8s容器化技术，监控，日志收集，网络安全，Python或GO开发，团队成员有乔克、wanger、冬哥、素心、华仔、郑哥、姜总、夏老师
相关推荐
运维开发故事-kubeadm安装采坑记录
kubeadm安装采坑记录
kubeadm安装采坑记录
3年前 2244
运维开发故事-k8s集成的可视化软件
k8s集成的可视化软件
k8s集成的可视化软件
3年前 828
运维开发故事-【K8S专栏】什么是云原生？
【K8S专栏】什么是云原生？
【K8S专栏】什么是云原生？
2年前 329
运维开发故事-开发和运维对K8S中的应用都做了什么？
开发和运维对K8S中的应用都做了什么？
开发和运维对K8S中的应用都做了什么？
2年前 327
运维开发故事-【夜莺监控】海王——Categraf
【夜莺监控】海王——Categraf
【夜莺监控】海王——Categraf
11月前 301
运维开发故事-大数据必知必会之Kafka
大数据必知必会之Kafka
大数据必知必会之Kafka
2年前 300

分类