來自 YAML 文件的 Jenkins 管道

Question

Jenkins 聲明式管道對我們來說太強大了，經常被用戶濫用。 我們正在考慮使用一個自以為是的 YAML 來描述 CI/CD 管道。 似乎有兩種選擇。

1. 寫一個插件消費 YAML 動態創建階段/步驟。
2. 編寫一個插件將 YAML 轉換為 Jenkins 管道。

我不是Jenkins方面的專家，所以我希望高手能給一些指導，也許是一個例子。

Answer 1

1. 使用官方插件pipeline-as-yaml ，但它有固定的語法。

2. 使用或定制wolox-ci

3. 創建您自己的共享庫。 然而，它們從一開始就很容易，但在廣泛使用時需要完整的語法設計。 這是一個基於curry的偽代碼。

// create a file named yamlCompiler.groovy in shared library,
def call(str){
  def rawMap = readYaml(text: str)
  // consume yaml and get a lambda function
  return {
    stage{
      steps.each{it ->
        it."$type"(it)
      }
    }
  }
}

在您的 jenkinsfile 代碼塊中使用yamlCompiler 。

@Library('your libs name')
def str = 
'''
steps:
 - type: sh
   script: ls -la 
 - type: echo
   message: xxx
'''
Closure closure = yamlCompiler(str)
closure.call()

Answer 2

我正在尋找類似的解決方案。 我們為每個項目運行強化的預定義管道，但仍希望允許開發團隊自定義流程中的某些步驟——但不允許他們使用 Jenkinsfile 的全部功能。

我也在探索——用你的話說—— “自以為是的 YAML”的可能性。

到目前為止，我只找到了一個這樣的實現示例：Wolox-CI 通過 YAML 支持他們自己的預定義構建步驟。您將能夠在此處看到他們支持的步驟。

我正在考慮使用 Snake YAML 解析 YAML。這是一個 SO 答案，其中包含有關如何執行此操作的示例。

Answer 3

兩種解決方案：

• 創建一個共享庫來抽象實際的管道，並為您的用戶提供一些關於如何設置共享庫和 Jenkinsfile 示例的指導。 這是嵌入式管道的示例https://github.com/SAP/jenkins-library/blob/master/vars/piperPipeline.groovy
• 使用其他工具，例如https://drone.io/

如果您不是專家並且不想/沒有時間成為專家，那么第二種解決方案可能是最好的。

Answer 4

Jenkins 聲明式管道對我們來說太強大了，經常被用戶濫用。 我們正在考慮使用自以為是的 YAML 來描述 CI/CD 管道。 而且似乎有兩種選擇。

1. 編寫一個插件並使用 YAML 並動態創建階段/步驟。
2. 編寫一個插件來將 YAML 轉換為 Jenkins 管道。

我不是 Jenkins 方面的專家，所以我希望一些專家能給一些指導，也許可以舉個例子。

Answer 5

真的嗎？ 執行插件時唯一的區別是這里嗎？：

1. 寫一個插件消費 YAML 動態創建階段/步驟。
2. 編寫一個插件將 YAML 轉換為 Jenkins 管道。

原諒我，因為我可能有點頑固，但是為動態創建聲明式或腳本化的 Jenkinsfile 抽象層，用簡單的 groovy lang 語法編寫，以便它可以漂亮地打印在 yml 中，防止用戶更新你的 yml具體如何？ 在我看來，您的抽象只會增加您希望實現可用性的復雜性。

第一，所有當前 Jenkins 的 yml 插件都是這樣做的。 第二，它們實際上並沒有通過實現 Jenkins 域（引用 DSL）中已經可用的 groovy/(java) 類來訪問的全部“功能”（是的，我在這里松散地使用該術語）。 目前有兩種解決方案，我已經調查並廣泛實施了這兩種解決方案。 一個是 wolox-ci，這是兩者中較好的一個，另一個是 Pipeline-as-YAML。 在我看來，它很容易使用，但兩者都缺乏僅使用 groovy 提供的全部實現功能。 那為什么要強制呢？ 只是為了讓您的用戶可以擁有一個打印精美的 yml 文件，而不必關心簡單的語法，您聲稱這會強化您的基礎設施即代碼后端，以便相同的用戶不會搞砸它？ 抱歉，我認為這種說法是胡說八道。 是什么阻止任何人通過將更改推送到 yml 文件來完全搞砸您的構建，這會破壞與 groovy 的集成，或者更糟糕的是，完全更改您努力定制的算法？

對不起，我只是不明白。 當然，讓一些東西更具可讀性總是一件好事。 但是，因為您規定的原因而這樣做是沒有意義的。 此外，除非您在 CI/CD 過程中有一個超級簡單的定義算法，沒有實現任何非連續傳遞式轉換方法，否則使用 yml-as-Jenkinsfile-templates 插件的當前迭代可能不是你想要的方式 go。

現在，您可以編寫自己的插件來執行此操作，但與僅學習 groovy 語法相比，技術債務是什么？ 此外，它仍然不會阻止用戶對您的構建基礎結構進行代碼更改，然后將這些更改集成到一個簡單的 yml 文件中。