背景：

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/v1kind: Deploymentmetadata:  name: xxxxspec:  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排序齐全没有法则....感觉没有解决好......

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

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