Kanade chilianyi devops-system里面的所有负载都重启试过了，连ks-controller-manager都重启过了，起来以后还是一样的结果。 这个问题也不是必现，但是几率挺大。
chilianyi 应该被 devops controller 给删掉了。 devops controller 向 jenkins 中触发构建，获得 id，然后再用这个 id 去 jenkins 中查详情时，没有查到，就报错，然后触发了删除动作。
Kanade chilianyi jenkins面板是能看到记录的，即便在Kubesphere删除之后，莫非是Kubesphere查的时候，Jenkins还没创建好记录…… 会不会和3.3.2的记录同步更新有关系
chilianyi Kanade 看你提供的这个截图，trigger 和 not exist in jenkins，delete it 相差只有几 ms。 trigger 的时候，会触发生成一个 jenkins 的构建记录，并获取到 id 然后再去 jenkins 中查这个 id，返回不存在，这个时间 很短，几 ms，然后触发了 delete。 jenkins 里还能看到，只是 devops 流水线里把记录删掉了。
chilianyi Kanade 是个 bug，已经记录：kubesphere/ks-devops#920 会有人跟进修复，然后给你下反馈，应该可以临时在 3.3.2 基础上 build 个 image，给到你。
yudong Kanade 针对这个问题，构建了一个临时镜像，麻烦更新下镜像验证下； 更新 devops-controller 镜像的命令： kubectl patch cc ks-installer -n kubesphere-system –type=json –patch ‘[{“op”: “replace”, “path”: “/spec/ks_devops_controller/repo”, “value”: “jackwithdocker/devops-controller”}, {“op”: “replace”, “path”: “/spec/ks_devops_controller/tag”, “value”: “ks-v3.3.2-patch”}]’ kubectl patch deployment devops-controller -n kubesphere-devops-system –patch ‘{“spec”: {“template”: {“spec”: {“containers”: [{“name”: “ks-devops”,“image”: “jackwithdocker/devops-controller:ks-v3.3.2-patch”}]}}}}’
yudong Kanade 第一条命令报这个错误是由于之前没有执行过 patch，可以把第一条命令换成这个： kubectl patch cc ks-installer -n kubesphere-system –type=json –patch ‘[{“op”: “add”, “path”: “/spec/ks_devops_controller”, “value”: {“repo”: “jackwithdocker/devops-controller”, “tag”: “ks-v3.3.2-patch”}}]’
Kanade yudong 非常给力，问题没再出现 不过感觉Jenkins还是有点经不住折腾，我这里出现了一个删不掉的文件夹，在Jenkins面板上删除也会报错，应该不是Kubesphere的问题。 另外请教个旁的事，把流水线运行结果存在ConfigMap里是出于什么考虑呢？感觉这样集群配置字典里的东西会越积越多
yudong Kanade 运行结果存到 ConfigMap 是因为有些流水线 step 结果数据量比较大，存 Annotation 里超出了 k8s 的限制；一个 Pipelinerun 存一个 ConfigMap，清理 Pipelinerun 的时也会同步清理掉对应的 ConfigMap；
Kanade yudong 一个小建议 在集群管理页面的配置字典里，通过项目过滤下拉单，查不到Devops项目，不过隶属于Devops项目的ConfigMap都在配置字典列表里，多了以后可能前十几页都是这些，对管理员来说不影响使用，但是感受上不够精简，重复的东西比较多。 如果能把这些东西在这里隐藏掉，或者放到Devops项目里展示，可能显得更整洁一些
