平行矩阵和没有种族条件的全球变量?

发布于 2025-02-09 19:13:41 字数 1325 浏览 0 评论 0原文

我有以下声明的管道,其中我在并行矩阵期间编写全局变量, write stage 可能是构建检测可能是(wasn''我很清楚)种族条件,但我不确定。我有3个有关以下简单管道的问题:

  1. 由于构建 - 检测使用相同的代理(仅注意build使用其他代理),这绝对是一个绝对是一个种族条件?
  2. 如果我要为每个并行行有一个代理,那将不是种族条件,因为每个代理中的全局build都不同吗?
  3. 有没有办法在舞台内部制作build的可变副本,以使其不再是全局?
  4. 我们应该如何处理全局变量通信内容( speps等时)和Parallel 矩阵功能?

Map<String,Boolean> build

pipeline {
  stages {
    stage('Test') {
      failFast false
      matrix {
        axes {
          axis {
            name 'CONTAINER'
            values 'A', 'B'
          }
        }
        stages {
          stage('Build Detection') {
            steps {
              script {
                build[CONTAINER] = CONATAINER == 'A'
                echo "Should Build: ${build[CONTAINER]}"
              }
            }
          }
          stage('Build') {
            agent {
              kubernetes {
                yamlFile '.jenkins/pods/build-kaniko.yaml'
              }
            }
            when {
              beforeAgent true
              expression { return build[CONTAINER] }
            }
            steps {
                echo "BUILDING....."
            }
          }
        }
      }
    }
  }
}

I have the following declarative pipeline where I write a global build variable during a parallel matrix, the write in stage Build Detection is probably (wasn't clear to me) a race condition but I am not sure. I have 3 questions regarding the below simple pipeline:

  1. Is it correct that since Build-Detection uses the same agent (note only Build uses a different agent), it is definitely a race condition ?
  2. If I would have one agent for each parallel line, it would not be a race condition as the global build is different in each agent?
  3. Is there a way to make a variable copy of build inside the stage such that it's not global any more?
  4. How should we deal with global variable communicating stuff (for when steps etc) and parallel matrix feature?

Map<String,Boolean> build

pipeline {
  stages {
    stage('Test') {
      failFast false
      matrix {
        axes {
          axis {
            name 'CONTAINER'
            values 'A', 'B'
          }
        }
        stages {
          stage('Build Detection') {
            steps {
              script {
                build[CONTAINER] = CONATAINER == 'A'
                echo "Should Build: ${build[CONTAINER]}"
              }
            }
          }
          stage('Build') {
            agent {
              kubernetes {
                yamlFile '.jenkins/pods/build-kaniko.yaml'
              }
            }
            when {
              beforeAgent true
              expression { return build[CONTAINER] }
            }
            steps {
                echo "BUILDING....."
            }
          }
        }
      }
    }
  }
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

自此以后,行同陌路 2025-02-16 19:13:41
  1. 不,它与构建代理无关。执行编译的Groovy代码的JVM正在詹金斯大师(Jenkins Master)上运行,而不是构建代理。因此,在Jenkins Master JVM中运行的每个线程共享使用全局变量。是否存在种族条件与使用相同或不同的构建剂的阶段无关。

  2. 与1。

    相同的答案

  3. ,只需在舞台脚本块中使用“ DEF”或特定类型定义变量。只需确保不带有类型的新变量,因为在Groovy中会导致它在全球范围内声明。

  4. 使用具有特定于每个线程的键的地图,就像您所做的那样,对我来说似乎是一种好方法。如果您真的想确保没有可能同时修改映射的两个不安全线程操作,请确保使用螺纹保护映射。您可以打印出地图的类,以找出实例化的实现。我希望这是href =“ https://docs.oracle.com/javase/8/docs/api/java/java/java/util/concurrent/concurrent/concurrenthashmap.html- >。

  1. No, it has nothing to do with build agents. The JVM that's executing the compiled groovy code is running on the Jenkins master, not a build agent. Therefore, using a global variable is shared by each thread running in the Jenkins master JVM. Whether there's a possible race condition is not related to stages using the same or different build agents.

  2. Same answer as 1.

  3. Yes, simply define a variable using "def" or a specific type in the stage's script block. Just be sure to not reference a new variable without a type because in Groovy that causes it to be declared globally.

  4. Using a map with a key that is specific to each thread like you're doing seems like a good way to me. If you really want to make sure there is no possibility of two unsafe thread operations modifying the map at the same time, then make sure that a threadsafe map is used. You could print out the class of the map to find out what implementation is getting instantiated. I would hope it's something threadsafe like ConcurrentHashMap.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文