用Tekton折腾自动化流水线，感觉还能更灵活点吧

朋友之前跟我吐槽，说他们团队最近在用Tekton搞CI/CD流水线，就是那种自动打包代码、跑测试、然后部署到服务器上的工具链，他说功能是挺强大的，毕竟是Kubernetes“原住民”，一切资源都是CRD，用YAML来定义，跟云原生那一套很搭，但用着用着，他就觉得有点不对劲，感觉这玩意儿“太正经”了，不够灵活,有种被框住的感觉。

他举了个例子，说是有次就想在构建镜像前，加一个非常简单的步骤：检查一下当前代码库的某个特定文件有没有被修改，如果有，就发个通知到钉钉群；如果没有，就跳过这个步骤，继续后面的构建，听起来就是个简单的if-else判断,对吧？

结果他在Tekton里折腾了半天，这不像在Jenkins里写脚本，可以直接在Jenkinsfile里用几行Groovy代码读文件、做判断，Tekton的一切都得“资源化”，他得先创建一个Task（任务）来执行检查文件的脚本，这个脚本还得写在容器镜像里，或者用一段很长的shell命令，这还没完，因为要做条件判断，他必须得用上When表达式，在Pipeline（流水线）里定义这个Task执行的条件。

来源：朋友的实际项目经验

问题就出在这个When表达式上，When表达式能判断的参数很有限，主要是Task的运行结果（比如上一个Task是成功还是失败），或者是一些预设的参数，他想判断的“某个文件是否变更”这个信息，是需要在Pipeline运行过程中动态计算出来的，并不是一开始就知道的,这就麻烦了。

他最后的解决方案非常“Tekton式”：他不得不先创建一个专门的Task，这个Task的唯一目的就是运行一个脚本，脚本会检查git的diff，判断那个文件有没有变，然后把结果（比如一个有变，一个没变）写入到某个地方，比如一个叫“workspace”的共享存储空间，或者干脆把这个结果作为一个输出参数，在后面那个“发通知”的Task上，再通过When表达式去引用前面那个Task产生的输出参数,来判断是否执行。

来源：对Tekton官方文档中When表达式和Task结果传递的理解

听他讲完，我笑了，这不就是“杀鸡用牛刀”吗？为了一个简单的逻辑判断，他硬生生地多创建了一个Task，定义了额外的输入输出，增加了Pipeline的复杂度和维护成本，他叹了口气说：“对啊，感觉就像是为了遵守某种架构规范，把简单的逻辑拆解得支离破碎，我只是想写个if语句而已，却感觉像是在组装一台精密的机器，每个螺丝都得拧到位。”

这让我想到，Tekton的这种设计哲学，优点和缺点是并存的，优点是声明式、可追溯、标准化，所有步骤都是Kubernetes资源，状态清晰，非常适合在复杂的、对稳定性和可观测性要求高的生产环境中使用，但缺点就是，对于需要快速迭代、有很多轻量级、临时性定制需求的场景，就显得有些笨重和僵化。来源：个人对声明式流水线和脚本式流水线差异的思考

他说，有时候他们只是想快速验证一个想法，做一个临时的A/B测试，或者处理一些边缘性的、非标准的构建流程，在这些时候，他们更怀念像GitHub Actions或者甚至直接写Shell脚本的那种“直给”的灵活性，在GitHub Actions的workflow文件里，你可以很方便地使用内置的github.event上下文和if条件，直接判断文件变更，几乎不需要额外的“基础设施”投入。来源：与GitHub Actions工作流文件的直观对比

“那你们有没有想过混着用？”我问他，核心的、稳定的构建和部署流程用Tekton来保证规范性，而那些灵活的、临时的、边缘性的小任务，就用更轻量的工具，比如跑个简单的Jenkins Job,或者直接用Kubernetes的CronJob来实现。

他说团队内部确实讨论过这个方案，这叫“混合云”模式，但这样做又引入了新的技术栈，带来了新的运维复杂度和学习成本，本来选用Tekton就是希望统一技术栈，减少维护负担，现在又要走回头路,感觉有点矛盾。

聊到最后，他觉得问题可能不出在Tekton本身，而在于团队如何定位它，如果把Tekton当作一个适用于所有场景的“银弹”，那肯定会遇到灵活性的天花板，但如果能接受它的“重”，明确它的边界，把它用作核心流水线的基石，同时允许在特定场景下使用更灵活的工具作为补充,或许心态就能更平和一些。

他说，下一步他们打算好好梳理一下现有的流程，把那些真正核心的、标准的流程用Tekton固化下来，而把那些频繁变化的、探索性的需求剥离出来，用其他方式实现，或许，在追求自动化的道路上，本来就不存在一劳永逸的完美工具，更重要的是根据实际情况，找到一种动态的、平衡的协作方式。来源：朋友团队后续的规划和反思