如果您正在寻找自动化的“PullRequest”或基于分支的JenkinsCI/CD管道，本指南将很好地概述如何使用JenkinsMulti-Branch进行操作流水线。Jenkins多分支管道是设计CI/CD工作流的最佳方式之一，因为它是完全基于git的管道即代码。在本指南中，我将讨论Jenkins多分支管道设置中涉及的所有关键概念让我们从多分支管道基础知识开始。具体来说，在本节中，我将描述什么是多分支管道，以及为什么使用它对于所有JenkinsCI/CD管道都是必不可少的。我还将向您展示多分支管道如何使用详细的工作流程图。多分支流水线是一种基于Git分支自动创建Jenkins流水线的概念。这意味着，它可以自动发现在SCM(Github)中创建的新Git分支，并自动为该分支创建管道。当管道构建开始时，Jenkins使用该分支中的Jenkinsfile进行构建阶段。SCM可以是Github、Bitbucket或Gitlab存储库。如果不希望选择的分支出现在带有Java正则表达式的自动流水线中，可以选择排除。多分支管道支持基于PR的分支发现。这意味着如果有人从一个分支发出PR（拉取请求），该分支会自动在管道中被发现。如果启用此配置，则只有在提出PR时才会触发构建。因此，如果您正在寻找基于PR的Jenkins构建工作流，这是一个不错的选择。您可以向Jenkinsfile添加条件逻辑，以根据分支要求构建作业。例如，如果你想让特性分支只运行单元测试和Sonar分析，你可以使用when条件设置一个条件来跳过部署阶段，如下所示。因此，每当开发人员从功能分支向另一个分支提交PR时，管道将运行单元测试和声纳分析阶段，跳过部署阶段。此外，多分支管道不限于持续交付应用程序。您还可以使用它来管理基础设施代码。多分支管道如何工作？我将引导您完成基本的构建和部署工作流程，以了解多分支管道的工作原理。假设我希望Jenkins管道在以下条件下构建和部署应用程序。开发人员通过向功能分支提交代码来开始功能分支。每当开发人员从功能分支中拉取PR来开发分支时，Jenkins管道应该触发运行单元测试和静态代码分析。开发者在feature分支测试代码成功后，将PR合并到develop分支。当代码准备好发布时，开发人员从develop分支向master提出PR。它应该触发一个构建管道，该管道将运行单元测试用例、代码分析并部署到开发/QA环境。从上面的情况可以看出，没有手动触发Jenkins作业，每当有分支pullrequest时，需要自动触发流水线并为该分支运行所需的步骤。此工作流为工程师建立了一个很好的反馈循环，并避免依赖DevOps团队在非生产环境中构建和部署。开发者可以在Github上查看构建状态并决定下一步做什么。使用Jenkins多分支管道可以轻松实现此工作流。下图显示了上面示例构建过程的多分支管道工作流的样子。这就是多分支管道的工作原理。当开发人员从功能分支创建PR以开发该分支时，Github会向Jenkins发送一个带有PR信息的webhook。Jenkins收到PR，找到相关的多分支流水线，自动创建分支流水线。然后它按照功能分支中Jenkinsfile中提到的步骤运行作业。在结帐期间，合并PR中的源分支和目标分支。在Jenkins返回构建状态之前，PR合并将在Github上被阻止。构建完成后，Jenkins会将状态更新为GithubPR。现在您将能够合并代码。另外，如果你想查看Jenkins构建日志，你可以在PR状态下找到Jenkins构建日志链接。MultibranchPiplelineJenkinsfile在开始实现之前，让我们看一下可以在流水线中使用的多分支流水线Jenkins示例Jenkinsfile。为了使多分支管道工作，您的SCM存储库中需要有一个Jenkinsfile。如果您正在学习/测试，您可以使用下面提供的多分支管道Jenkinsfile。它有一个结帐阶段和其他回显消息的阶段。或者，您可以使用此Jenkinsfile克隆和使用Github存储库注意：将代理标签“master”替换为您的Jenkins代理名称。master也可以，但是不建议在真实项目环境下运行。pipeline{agent{node{label'master'}}options{buildDiscarderlogRotator(daysToKeepStr:'16',numToKeepStr:'10')}stages{stage('CleanupWorkspace'){steps{cleanWs()sh"""echo"CleanedUpWorkspaceForProject""""}}stage('CodeCheckout'){steps{checkout([$class:'GitSCM',branches:[[name:'*/main']],userRemoteConfigs:[[url:'https://github.com/spring-projects/spring-petclinic.git']]])}}stage('UnitTesting'){steps{sh"""echo"RunningUnitTests""""}}stage('CodeAnalysis'){steps{sh"""echo"RunningCodeAnalysis""""}}stage('BuildDeployCode'){when{branch'develop'}steps{sh"""echo"BuildingArtifact""""sh""echo"DeployingCode"""》}}}}搭建JenkinsMultibranchPipeline在这里，我将一步一步地指导你在Jenkins上搭建一个多分支管道。搭建将基于Github和最新的Jenkins2.x版本。你也可以使用Bitbucket或Gitlab作为多分支流水线的SCM源第1步：在Jenkins主页上创建一个“新项目”。第2步：从选项中选择Multi-BranchPipeline，然后单击OK。第三步：点击“添加源”，选择Github。第4步：在身份验证字段下，选择Jenkins并使用您的Github用户名和密码创建身份验证。第5步：选择创建的凭据并提供您的Github存储库以验证凭据，如下所示。如果您正在测试多分支管道，您可以克隆演示Github存储库并使用它。https://github.com/devopscube/multibranch-pipeline-demo。第6步：选择所需的选项以满足您的要求。您可以选择发现存储库中的所有分支，或仅发现具有合并请求的分支。管道还可以从分叉的存储库中发现带有PR的分支。选择这些选项取决于所需的工作流程。您可以从“添加”按钮中选择其他行为。例如，如果您选择不从版本库中发现所有分支，您可以选择正则表达式或通配符方法从版本库中发现分支，如下所示。这是一个正则表达式和通配符示例。第7步：如果您选择为Jenkinsfile使用不同的名称，您可以通过在构建配置中指定名称来实现。在“脚本路径”选项中，您可以提供所需的名称。确保您在存储库中有一个Jenkinsfile，其名称与您在管道配置中为其指定的名称相同。此外，启用“丢弃旧版本”以仅保留所需的构建日志，如下所示。第8步：保存所有作业配置。Jenkins扫描已配置的Github存储库以查找所有提出PR的分支。下图显示了一个扫描三个分支的作业，由于我没有发出任何拉取请求，Jenkins不会创建任何基于分支的管道。我将展示如何在设置webhook后测试自动管道创建。至此，我们已经将Jenkins配置为根据PR请求扫描分支。为了有一个完整的工作流程，我们需要在Github中配置一个webhook以将所有事件（提交、PR等）发送到Jenkins，因为管道可以自动触发。要为多分支管道配置webhook，请按照以下步骤在存储库上设置Jenkinswebhook。第1步：转到Github存储库并单击“设置”。第二步：选择左侧的webhook选项，点击“添加Webhook”按钮。第3步：在有效负载URL下添加您的JenkinsURL，后跟“/github-webhook/”。选择内容类型为“application/json”，点击“AddWebhook”注意：你可以在Jenkins中选择你想要接收的webhook类型。例如，您只想在PR期间触发管道。然后，您可以从“让我选择个别事件”选项中仅选择PR事件。您将在成功的webhook配置上看到一个绿色勾号，如下所示。如果您没有看到绿色勾号或警告标志，请单击Webhooks链接，然后单击最后一个Webhook。您应该能够使用状态代码来查看webhook传递失败的原因。我们现在拥有多分支管道所需的所有配置。下一步是测试多分支管道工作流触发器。测试多分支管道出于演示目的，我选择了“BranchonlyasaPR”选项。使用此选项，只会发现具有PR请求的分支。要使用多分支管道，您可以将此存储库与示例Jenkinsfile一起使用。https://github.com/devopscube/multibranch-pipeline-demo这个仓库有三个分支。在功能分支的README中更新一些内容并为开发提出PR。它将向Jenkins发送一个webhook，Jenkins会将工作详细信息发回给Jenkins，PR将进入审查状态，如下所示。如果单击“详细信息”，它将带您到Jenkins构建日志。您可以在Jenkins文件中编写自定义检查以用于构建审核。现在，如果您选择了Jenkins，您将在Jenkins中找到功能分支的管道，如下所示。如果构建失败，可以将更改提交到功能分支，并且只要PR打开，它就会触发功能管道。在Jenkinfile中，我添加了一个条件，如果分支未开发则跳过部署阶段。您可以查看Jenkins构建日志。此外，如果您在蓝海仪表板中检查构建过程，您可以清楚地看到跳过的部署阶段，如下所示。现在合并功能分支PR并将新的PR从develop分支提升到master分支。Jenkins将从Github接收一个用于新PR的webhook，并创建一个开发管道，如下所示。develop分支开启了deploy阶段，查看BlueOcean的构建过程，可以看到所有阶段都成功触发。多分支管道故障排除我将讨论您在多分支管道中可能遇到的一些错误以及如何解决这些错误。分支发现问题有时，即使在SCM中创建了新分支，它也可能不会反映在Jenkins管道中。您可以尝试运行“立即扫描存储库”选项以再次扫描存储库。此外，检查管道中的存储库扫描配置。Webhooks不触发管道当webhooks不触发管道时，检查Github中的webhook交付状态代码和错误。此外，检查JenkinsURL是否正确。还要从管理Jenkins->系统日志->所有Jenkins日志中检查Jenkins日志。如果Jenkins能够接收到webhook，则日志应显示未触发作业的原因。
