关于jenkins:jenkins-harbor-webhook自动触发构建

48次阅读

共计 4275 个字符,预计需要花费 11 分钟才能阅读完成。

背景:

cicd 还是基于 jenkins(spinnaker 尽管也玩了,公司规模也小,简略 jenkins 能够走天下)其实很多场景还是手动构建的,根本没有做主动构建的 jenkins 流程。明天就忽然有了那么一个需要。合作方大爷要频繁批改一个镜像。恩他们构建了镜像上传到仓库(仓库咱们的,对方木有),他们也不想第二次操作 jenkins 什么的 … 当然了他们也不会把代码仓库给到咱,而后我就想到了 jenkins 的构建触发器 -Generic Webhook Trigger去触发构建。

jenkins-harbor webhook 主动触发构建

对于 jenkins 的触发器插件:

搜寻插件名称:Generic Webhook Trigger

重启 jenkins 后,进入一个 Pipeline 我的项目设置,曾经能够抉择这个触发器了 ….

这里就疏忽了,我这里早装置了插件好多年了 ……

harbor or ccr 仓库 webhook

其实我的镜像仓库应用了腾讯云的 tcr 镜像仓库, 仓库能够配置触发器

看了一眼文档触发器操作指南:

顺便看了一眼 harbor 的示例:https://www.1nth.com/post/jenkins_webhook/

参数构造目测都一样的间接拿来用了!

jenkins Generic Webhook Trigger pipeline

jenkins 创立 pipeline

新建一个工作,自定义工作名称,抉择流水线 pipeline 形式:
间接写 pipeline 了:

pipeline {
    agent any
    triggers {
      GenericTrigger(
              genericVariables: [[key: 'harbor_type', value: '$.type', expressionType: 'JSONPath'],
                [key: 'harbor_image', value: '$.event_data.resources[0].resource_url', expressionType: 'JSONPath'],
                [key: 'image_tag', value: '$.event_data.resources[0].tag', expressionType: 'JSONPath'],
                [key: 'harbor_namespace', value: '$.event_data.repository.namespace', expressionType: 'JSONPath'],
                [key: 'repo_name', value: '$.event_data.repository.name', expressionType: 'JSONPath'],
              ],
              token: 'xxxxxxx' ,
              causeString: 'Triggered on $branch' ,
              printContributedVariables: true,
              printPostContent: true,
              //regexpFilterText: '$ref',
              //regexpFilterExpression: 'refs/heads/' + BRANCH_NAME
              regexpFilterText: '$harbor_type#$harbor_namespace#$repo_name',
              regexpFilterExpression: 'pushImage#xxxx#xxxx'
          )
    }
    stages {stage('Hello') {
            steps {
                sh '''
                echo harbor_type=$harbor_type
                echo harbor_image=$harbor_image
                echo harbor_image=$image_tag
                echo repo_name=$repo_name
                echo harbor_namespace=$harbor_namespace
                echo "do something..."
                #kubectl set image deployment.apps/$repo_name $repo_name=$harbor_image
                '''
            }
        }
    }
}

镜像仓库创立触发器:

设置 名称 ,触发动作抉择了 推送镜像,命名空间,仓库名称 设置好 ,版本 tag 空。url 的格局为:

https://jenkins.xxx.com/generic-webhook-trigger/invoke?token=xxxxxx

token 为下面 pipeline 脚本中设置的 token 内容

绝对于 https://www.1nth.com/post/jenkins_webhook/。我减少了一个 image_tag 的字段。因为我每次都是批改 tag 版本标签的。习惯这样了. 前面会用到这个 image_tag(变量的名称其实都能够自定义,不肯定用示例中的,我是偷懒,懒得改了)

构建镜像 push 测试

顺手 push 一下镜像到镜像仓库:

docker push  xxxx.xxxx.com/xxxx/xxxx:v2

看了一眼腾讯云镜像仓库的触发器:

jenkins 主动触发构建胜利:

下一步欠缺到 kubernetes 公布:

步骤就是 sed 批改 tpl 到 yaml 文件而后 apply yaml 文件公布!
持续欠缺一下 pipeline:

pipeline {
    agent any
    triggers {
      GenericTrigger(
              genericVariables: [[key: 'harbor_type', value: '$.type', expressionType: 'JSONPath'],
                [key: 'harbor_image', value: '$.event_data.resources[0].resource_url', expressionType: 'JSONPath'],
                [key: 'image_tag', value: '$.event_data.resources[0].tag', expressionType: 'JSONPath'],
                [key: 'harbor_namespace', value: '$.event_data.repository.namespace', expressionType: 'JSONPath'],
                [key: 'repo_name', value: '$.event_data.repository.name', expressionType: 'JSONPath'],
              ],
              token: 'xxxxx' ,
              causeString: 'Triggered on $branch' ,
              printContributedVariables: true,
              printPostContent: true,
              //regexpFilterText: '$ref',
              //regexpFilterExpression: 'refs/heads/' + BRANCH_NAME
              regexpFilterText: '$harbor_type#$harbor_namespace#$repo_name',
              regexpFilterExpression: 'pushImage#xxxx#xxxx'
          )
    }
    stages {stage('Hello') {agent { label  "xxxx"}
            steps {sh "sed -e's/{image_tag}/$image_tag/g'/home/xxxx/jenkins/yaml/xxxx/xxxx.tpl > /home/xxxx/jenkins/yaml/xxxx/xxxx.yaml"
               sh "sudo kubectl apply -f /home/xxxx/jenkins/yaml/xxxx/xxxx.yaml --namespace=xxxx"                
                // sh '''
                // echo harbor_type=$harbor_type
                // echo harbor_image=$harbor_image
                // echo harbor_image=$image_tag
                // echo repo_name=$repo_name
                // echo harbor_namespace=$harbor_namespace
                // echo "do something..."
                // #kubectl set image deployment.apps/$repo_name $repo_name=$harbor_image
                // '''
            }
        }
    }
}

留神:regexpFilterExpression: ‘pushImage#xxxx#xxxx’ 的格局。能够本人关注一下Optional filter 正则匹配(其实也能够偷懒不加,看集体吧)

演示先屏蔽了 apply 过程。只 sed 批改 tpl 文件为 yaml 文件:
xxx.tpl 模板

apiVersion: apps/v1
kind: Deployment
metadata:
  name: xxxx
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
  selector:
    matchLabels:
      app: xxxx
  template:
    metadata:
      labels:
        app: xxxx
    spec:
      containers:
        - name: xxxx
          image: xxxx.xxxx.com/xxxx/xxxx:{image_tag}
          envFrom:
          - configMapRef:
              name: xxxx
          ports:
            - containerPort: 3000
              protocol: TCP
          resources:
            requests:
              memory: "256M"
              cpu: "250m"
            limits:
              memory: "2048M"
              cpu: "2000m" 
      imagePullSecrets:                                              
        - name: xxxx

看一下生成的 yaml 文件:

例子其实就是一个 wiki 我的项目。这样根本就完了。当然了我这里用的简略指定了执行的 agent

 agent {label  "xxxx"}

stage 的名字也能够换一下,这里偷懒了 hello 都没有批改

        stage('Hello') {}

良久不必了触发器,这里就记录一下 ……

而后吐槽一下腾讯云 tcr 镜像服务的触发器:

工作状态的排序

这里说的是谬误 or 胜利的排序,首先在触发器工作重谬误的优先级没有那么高,所以将谬误排在后面齐全没有必要:

失常的排序也齐全没有法则

这工作的 id 排序齐全没有法则 …. 感觉没有解决好 ……

起初我又触发了几次工作程序更是可怕,这也没有失败的优先了?怎么排序的?且排序的失败的工夫格局也与失常的不统一?

曾经反馈给相干人员期待能欠缺一下,就失常的工作排序就好了最多做一个成功失败的勾选,这排序体验太差了 …..

正文完
 0