在并行阶段中跨多个节点重用工作空间

Question

我的 Jenkins 管道脚本中有并行阶段设置，它在不同的节点（AWS EC2 实例）上执行测试

例如

stage('E2E-PR') {
    parallel {
        stage('Cypress Tests 1') {
            agent { label 'aws_slave_cypress' }
            steps {
                runE2eTests()
            }
        }
        stage('Cypress Tests 2') {
            agent { label 'aws_slave_cypress' }
            steps {
                runE2eTests()
            }
        }
    }
}

我想重新使用从管道开始时使用的父节点生成的签出的存储库\生成的工作空间，而不是每个并行阶段都签出它自己的副本。

我遇到了一种使用顺序阶段和阶段内嵌套阶段来跨多个阶段共享工作空间的方法，我尝试如下

parallel {
    stage('Cypress Tests') {
        agent { label 'aws_slave_cypress' }
        stages {
            stage('Cypress 1') {
                steps {
                    runE2eTests()
                }
            }
            stage('Cypress 2') {
                steps {
                    runE2eTests()
                }
            }
        }
    }
}

但我可以从 Jenkins 构建输出中看到，只有一个 aws 实例启动并用于我的两个嵌套阶段，这并没有给我带来并行性的好处。

我也遇到过 stash\unstash 命令，但我读过这些命令应该用于小文件而不是大目录\整个存储库？

这里允许我跨多个节点使用相同的最初生成的工作空间的并行阶段的正确方法是什么？这可能吗？

谢谢

Answer 1

我可以分享一些关于我们公司类似情况的信息：我们有一个用于 UI 测试的自动化回归套件，需要在几台不同的机器（Win32、Win64、Mac 等）上执行。套件配置由包含所有相关环境参数和 URL 的配置文件控制。
该作业允许用户选择将执行的套件（以及 git 分支）、选择将在其上执行套件的标签（代理）以及选择这些套件将使用的环境配置。

流程如何：

1. 根据用户输入生成配置文件并保存（隐藏）它。
2. 对于所有给定标签并行：使用浅克隆克隆套件存储库 -> 复制配置文件 (unsatsh) -> 运行测试 -> 保存（存储）测试的输出。
3. 收集所有测试的输出（取消存储），将它们组合成一个报告，发布报告并通知用户。

管道本身（简化）将如下所示：

pipeline {
    agent any
    parameters {
         extendedChoice(name: 'Agents', ...)
    }
    stages {
        stage('Create Config') {
            steps {
                // create the config file called config.yaml
                ...
                stash name: 'config' , includes: 'config.yaml'
            }
        }
        stage('Run Tests') {
            steps {
                script {
                    parallel params.Agents.collectEntries { agent ->
                        ["Running on ${agent}": {
                            stage(agent) {
                                node(agent) {
                                    println "Executing regression tests on ${agent}"
                                    stage('Clone Tests') {
                                        // Git - shallow clone the automation tests
                                    }
                                    stage('Update Config') {
                                        unstash 'config'
                                    }
                                    stage('Run Suite') {
                                        catchError(buildResult: 'FAILURE', stageResult: 'FAILURE') {
                                            // Run the tests
                                        }
                                    }
                                    stage('Stash Results'){
                                        stash name: agent , includes: 'results.json'
                                    }
                                }
                            }
                        }]
                    }
                }
            }
        }
        stage('Combine and Publish Report') {
            steps {
                // Unstash all results from each agent to the same folder
                params.Agents.each { agent ->
                    dir(agent){
                        unstash agent
                    }
                }
                // Run command to combine the results and generated the HTML report
                // Use publishHTML to publish the HTML report to Jenkins
            }
        }
    }
    post{
        // Notify users
    }
}

因此，正如您所看到的，处理相对较小的文件（例如配置文件和测试结果文件（小于 1M））stash并且unstash快速且非常易于使用并提供很大的灵活性，但是当您将它们用于更大的文件时，它们开始使系统超载。
关于测试本身，最终您必须将文件复制到不同代理中的每个工作区，如果您的测试未打包，则从存储库浅克隆它们可能是最有效且易于使用的方法。

如果您的测试可以轻松打包，例如 python 包，那么您可以创建一个不同的 CI 管道，将它们归档为每个代码更改的包，然后您的自动化管道可以将它们与 pip 等工具一起使用，并避免需要克隆存储库。
当您在容器中运行测试时也是如此，因为您可以创建一个 CI，它将准备一个已包含测试的映像，然后只需在管道中使用该映像，而无需重新克隆它。
如果您的 Git 服务器速度有点慢，您始终可以使用 zip 或类似的归档程序将测试打包到 CI 中，将它们上传到 S3（使用aws-steps）或等效工具，并在自动化管道执行期间下载它们 - 但在大多数情况下，这不会提供任何性能优势。