Logo

Menu

乔克
乔克
Published on 2024-11-15 / 39 Visits
0
0

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

#devops#zadig

最近因为公司的产研调整，决定将代码仓库从本地的 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。

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

如何通过Kubernetes安装K...
如何为你的Kubernetes保驾护航？

Comment