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



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


作者:乔克
公众号:运维开发故事
博客: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 nilnil, 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
分享