一、脚本式管道与声明式管道-四个实际差异¶
1.1 脚本式管道与声明式管道-四个实际差异¶
为什么要有两种管道类型？
- 脚本化管道是
Jenkins中作为代码的管道的第一个实现。即使它使用底层的管道子系统，它还是或多或少地设计为使用Groovy构建的通用DSL。这意味着它不具有固定的结构，并且由您决定如何定义管道逻辑。 - 声明性管道更自以为是，其结构是明确定义的。可能看起来有些局限。
但实际上，您可以使用脚本化或声明性管道来实现相同的目的。那么选择哪一个呢？如果您问我这个问题，我会说使用声明性管道。以下内容这就是为什么。
1.2 管道启动时的代码验证¶
pipeline {
agent any
stages {
stage("Build") {
steps {
echo "Some code compilation here..."
}
}
stage("Test") {
steps {
echo "Some tests execution here..."
echo 1
}
}
}
}
如果我们尝试运行以下管道，则验证将很快使构建失败。该日志显示只能与触发String参数，所以我们得到这样的错误。
请注意，管道没有执行任何阶段，只是失败了。这可能为我们节省了很多时间-想象一下执行Build阶段几分钟，而只是获取echo步骤希望得到的信息java.lang.String而不是java.lang.Integer。
现在，让我们看一下与该示例等效的脚本管道。
node {
stage("Build") {
echo "Some code compilation here..."
}
stage("Test") {
echo "Some tests execution here..."
echo 1
}
}
它按预期失败。但是这次是执行Build阶段，也是Test阶段的第一步。如您所见，没有验证管道代码。在这种情况下，声明式管道可以更好地处理此类用例。
1.3 从指定步骤重新开始¶
声明式管道具有的另一个很酷的功能是“从阶段重新启动”。让我们修复上一个示例中的管道，看看是否只能重新启动Test阶段。
pipeline {
agent any
stages {
stage("Build") {
steps {
echo "Some code compilation here..."
}
}
stage("Test") {
steps {
echo "Some tests execution here..."
}
}
}
}
让我们执行它。
在这里您可以看到已选择测试阶段。在右侧的步骤列表上方，有一个名为“重新启动测试”的选项。让我们单击它并查看结果。
如您所见，Jenkins跳过了Build阶段（它使用了先前构建中的工作空间），并从Test阶段开始了下一个管道执行。当您执行一些外部测试并且由于远程环境的某些问题而导致测试失败时，这可能会很有用。您可以使用测试环境解决问题，然后重新运行该阶段，而无需重建所有工件。（在这种情况下，应用程序的代码未更改。）
现在，让我们看一下脚本化管道示例。
node {
stage("Build") {
echo "Some code compilation here..."
}
stage("Test") {
echo "Some tests execution here..."
}
}
如您所见，没有重新启动选项。声明式管道与脚本式管道-2：0。
1.4 声明式管道options块¶
两种管道类型都支持第三个功能，但是我认为声明性管道更好地处理了它。假设我们将以下功能添加到上一个管道中。
- 控制台日志中的时间戳。
- ANSI颜色输出。
- 在1分钟的超时构建阶段，2分钟超时的测试阶段。
pipeline {
agent any
options {
timestamps()
ansiColor("xterm")
}
stages {
stage("Build") {
options {
timeout(time: 1, unit: "MINUTES")
}
steps {
sh 'printf "\\e[31mSome code compilation here...\\e[0m\\n"'
}
}
stage("Test") {
options {
timeout(time: 2, unit: "MINUTES")
}
steps {
sh 'printf "\\e[31mSome tests execution here...\\e[0m\\n"'
}
}
}
}
这是控制台日志。
Started by user unknown or anonymous
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on hostmachine in /home/vagrant/workspace/workspace/chap2-12comp2
[Pipeline] {
[Pipeline] timestamps
[Pipeline] {
[Pipeline] ansiColor
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Build)
[Pipeline] timeout
02:23:57 Timeout set to expire in 1 min 0 sec
[Pipeline] {
[Pipeline] sh
02:23:59 + printf '\e[31mSome code compilation here...\e[0m\n'
02:23:59 Some code compilation here...
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Test)
[Pipeline] timeout
02:23:59 Timeout set to expire in 2 min 0 sec
[Pipeline] {
[Pipeline] sh
02:23:59 + printf '\e[31mSome tests execution here...\e[0m\n'
02:23:59 Some tests execution here...
[Pipeline] }
[Pipeline] // timeout
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // ansiColor
[Pipeline] }
[Pipeline] // timestamps
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
在声明性管道中，选项与管道脚本逻辑分开。该脚本管道也支持timestamps，ansiColor和timeout选项，但它需要一个不同的代码。这是使用脚本化管道表达的相同管道。
node {
timestamps {
ansiColor("xterm") {
stage("Build") {
timeout(time: 1, unit: "MINUTES") {
sh 'printf "\\e[31mSome code compilation here...\\e[0m\\n"'
}
}
stage("Test") {
timeout(time: 2, unit: "MINUTES") {
sh 'printf "\\e[31mSome tests execution here...\\e[0m\\n"'
}
}
}
}
}
我想你看到了问题。在这里，我们仅使用timestamps和ansiColorJenkins插件。想象再添加一个或两个插件。声明式与脚本式，3：0。
1.5 用when块跳过阶段。¶
在此博客文章中我最后要提到的是when声明性管道支持的块。让我们改进前面的示例并添加以下条件：
- 仅在等于时执行测试阶段。
env.FOO=bar
这是声明性管道代码的外观。
pipeline {
agent any
options {
timestamps()
ansiColor("xterm")
}
stages {
stage("Build") {
options {
timeout(time: 1, unit: "MINUTES")
}
steps {
sh 'printf "\\e[31mSome code compilation here...\\e[0m\\n"'
}
}
stage("Test") {
when {
environment name: "FOO", value: "bar"
}
options {
timeout(time: 2, unit: "MINUTES")
}
steps {
sh 'printf "\\e[31mSome tests execution here...\\e[0m\\n"'
}
}
}
}
然后执行它。
node {
timestamps {
ansiColor("xterm") {
stage("Build") {
timeout(time: 1, unit: "MINUTES") {
sh 'printf "\\e[31mSome code compilation here...\\e[0m\\n"'
}
}
if (env.FOO == "bar") {
stage("Test") {
timeout(time: 2, unit: "MINUTES") {
sh 'printf "\\e[31mSome tests execution here...\\e[0m\\n"'
}
}
}
}
}
}
如您所见，我们必须使用if-condition来检查是否env.FOO等于bar，然后才添加Test阶段。（不幸的是，这并不是真正的跳过。）让我们运行它，看看结果如何。
这是不同的结果。在脚本化管道用例中，甚至不会呈现“ 测试”阶段。在我看来，这可能会带来一些不必要的混乱，声明性管道会更好地处理它。声明式与脚本式，4：0。
二、使用Jenkins Git参数实现分支标签动态选择¶
2.1 为什么要使用Git参数？¶
我们为什么要使用 git参数呢？每个项目代码库都会有不同的分支，（如果你没有用多分支流水线的情况下）对于普通的流水线项目我们可以 让一条流水线来支持多个分支的发布，其实有时候你会发现每个分支的集成步骤都是差不多的。如果出现差异步骤我们也可以在jenkinsfile中根据不同的分支执行不同的stage。
如何解决固定分支问题？起初我们的流水线项目配置分支可能是采用的选项参数。创建一个选项参数然后把项目经常用到的分支给更新上去，最后开发人员在发布的时候来选择对应的分支。看似解决了固定分支问题，但是后期维护起来非常困难，需要不断的更改参数值。
创建一个字符参数设置一个默认值，然后 交给开发人员自己填写。这样的确方便了配置管理人员，给开发人员增加了负担，手动输入避免不了带来了错误发生的可能。
我们来通过下面的内容，掌握如何使用 git参数实现动态分支构建呢？
2.2 在Pipeline项目中使用¶
这里把普通的pipeline项目定义为 未将Jenkinsfile内容保存在版本控制系统中，而是存储在该JOB中。
2.2.1 普通的Pipeline项目¶
首先我们添加一个srcUrl参数定义项目代码库的地址，便于后期在pipeline中调用。
srcUrl:http://192.168.1.200:30088/idevops/idevops-maven-service.gitbranchName:origin/master
编写Jenkinsfile
//pipeline
pipeline{
agent { node { label "build"}}
stages{
stage("CheckOut"){
steps{
script{
println("${branchName}")
checkout([$class: 'GitSCM', branches: [[name: "${branchName}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'gitlab-admin-user',
url: "${srcUrl}"]]])
}
}
}
}
}
对于将jenkinsfile保存在作业中，这种方式有利有弊，好处是可以方便我们进行代码调试，坏处是不利于统一管理。大家酌情使用。
2.2.2 流行的Pipeline项目¶
这里流行的Pipeline项目我们理解为此job使用的jenkinsfile文件存储在git版本控制系统中。
首先我们创建一个测试jenkinsfile,保存在git项目中，命名为git.jenkinsfile。此文件内容与上面那种方式是一样的，只不过将jenkinsfile纳入了版本控制。
//pipeline
pipeline{
agent { node { label "build"}}
stages{
stage("CheckOut"){
steps{
script{
println("${branchName}")
checkout([$class: 'GitSCM', branches: [[name: "${branchName}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'gitlab-admin-user',
url: "${srcUrl}"]]])
}
}
}
}
}
然后我们来创建一个新的流水线项目。注意情况我们现在用到了两个仓库，一个是Jenkinsfile仓库，另一个是项目代码仓库。创建一个参数srcUrl用于存储项目代码仓库的URL。
默认git参数会识别到Jenkinsfile的仓库，所以我们需要在git参数的高级设置中指定我们要使用的仓库地址。80%错误因为没有指定仓库导致获取分支错误等问题。
2.2.3 使用Pipeline as Code¶
我们将参数信息全部放到Jenkinsfile中存储。此时生成的代码就不区分在作业中保存还是在版本控制系统中保存了。不过还是建议大家把jenkinsfile纳入版本控制系统中保存。
我们如何生成Jenkinsfile代码？很方便的工具，我们导航到 流水线语法-> Declarative Directive Generator 。
最后完整的Jenkinsfile如下所示：
//pipeline
pipeline{
agent { node { label "build"}}
parameters {
string defaultValue: 'http://192.168.1.200:30088/idevops/idevops-maven-service.git',
description: '',
name: 'srcUrl',
trim: false
gitParameter branch: '',
branchFilter: '.*',
defaultValue: 'origin/master',
description: '',
name: 'branchName',
quickFilterEnabled: false,
selectedValue: 'NONE',
sortMode: 'NONE',
tagFilter: '*',
type: 'PT_BRANCH',
useRepository: 'http://192.168.1.200:30088/idevops/idevops-maven-service.git'
}
stages{
stage("CheckOut"){
steps{
script{
println("${branchName}")
checkout([$class: 'GitSCM', branches: [[name: "${branchName}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: 'gitlab-admin-user',
url: "${srcUrl}"]]])
}
}
}
}
}
同样的配置过程，我们构建 一次之后就能够 正常获取到项目代码库的分支信息了。
三、多分支类型管道- 基于Jenkinsfile自动创建Pipeline(2023)¶
3.1 多分支类型管道- 基于Jenkinsfile自动创建Pipeline(2023)¶
Jenkins多分支管道是设计CI/CD工作流的最佳方法之一，因为它完全是基于git的pipeline as code
多分支管道是一种基于Git分支自动创建Jenkins Pipeline的概念。这意味着，它可以在SCM（Github）中创建时自动发现新的Git分支，并自动为该分支创建管道。当管道构建开始时，Jenkins在该分支中使用Jenkinsfile进行构建阶段。
SCM可以是Github，Bitbucket或Gitlab存储库。
stage ('Deploy for production') {
when {
branch 'production'
}
steps {
...
}
}
因此，每当开发人员将PR从功能分支提交到其他分支时，管道将运行单元测试和Sonar分析阶段，从而跳过部署阶段。而且，多分支流水线不仅限于连续交付应用程序。您也可以使用它来管理基础结构代码
3.2 多分支管道如何工作？¶
我将引导您完成基本的构建和部署工作流程，以了解多分支管道的工作方式。
假设我希望Jenkins管道在以下条件下构建和部署应用程序。
1、开发人员通过向功能分支提交代码来从功能分支开始。 2、每当开发人员从功能分支提PR来开发分支时，Jenkins管道都应触发以运行单元测试和静态代码分析。 3、在功能分支中成功测试代码后，开发人员将PR合并到开发分支。 4、当代码准备发布时，开发人员将PR从develop分支提到master。它应该触发一个构建管道，该管道将运行单元测试用例，代码分析并将其部署到dev / QA环境。
通过Jenkins多分支管道可以轻松实现此工作流程。下图显示了以上示例构建过程的多分支管道工作流的外观
这是多分支管道的工作方式。
1、当开发人员从功能分支创建PR来开发分支时，Github将带有PR信息的Webhook发送给Jenkins。 2、Jenkins收到PR，并找到相关的多分支管道并自动创建分支管道。 - 然后，它按照功能分支中Jenkinsfile中提到的步骤运行作业。 - 签出期间，PR中的源分支和目标分支将合并。 - PR合并将在Github上被阻止，直到从Jenkins返回构建状态为止 3、构建完成后，Jenkins会将状态更新为Github PR。现在您将能够合并代码。 - 另外，如果您想查看Jenkins构建日志，则可以在PR状态下找到Jenkins构建日志链接。
3.3 多分支Pipleline Jenkinsfile¶
在开始实施之前，让我们看一下可在管道中使用的多分支管道Jenkins示例Jenkinsfile。
为了使多分支管道正常工作，您需要在SCM存储库中包含Jenkinsfile。
如果您正在学习/测试，则可以使用下面提供的多分支管道Jenkinsfile。它具有一个检出阶段和其他阶段，它们会回显消息。
另外，您可以克隆并使用具有此Jenkinsfile的Github存储库
注意：将代理标签“ master”替换为您的Jenkins代理名称。master也可以工作，但不建议它在实际的项目环境中运行。
pipeline {
agent {
node {
label 'master'
}
}
options {
buildDiscarder logRotator(
daysToKeepStr: '16',
numToKeepStr: '10'
)
}
stages {
stage('Cleanup Workspace') {
steps {
cleanWs()
sh """
echo "Cleaned Up Workspace For Project"
"""
}
}
stage('Code Checkout') {
steps {
checkout([
$class: 'GitSCM',
branches: [[name: '*/main']],
userRemoteConfigs: [[url: 'https://github.com/spring-projects/spring-petclinic.git']]
])
}
}
stage(' Unit Testing') {
steps {
sh """
echo "Running Unit Tests"
"""
}
}
stage('Code Analysis') {
steps {
sh """
echo "Running Code Analysis"
"""
}
}
stage('Build Deploy Code') {
when {
branch 'develop'
}
steps {
sh """
echo "Building Artifact"
"""
sh """
echo "Deploying Code"
"""
}
}
}
}
3.4 设置Jenkins多分支管道¶
在这里，我将逐步引导您逐步在Jenkins上建立多分支管道。该设置将基于Github和最新的Jenkins 2.x版本。您还可以将Bitbucket或Gitlab用作多分支管道的SCM源。
步骤1：在Jenkins主页上创建一个“新项目”。
步骤2：从选项中选择“多分支管道”，然后单击“确定”。
步骤3：点击“添加来源”，然后选择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，因为可以自动触发管道。
3.5 为多分支管道配置Webhook¶
请按照以下步骤在存储库上设置Jenkins Webhook。
第1步：转到Github存储库，然后单击设置。
步骤2：选择左侧的webhook选项，然后单击“添加Webhook”按钮。
步骤3：在有效负载URL下添加您的Jenkins URL，后跟“ **/github-webhook /”。选择内容类型为“ application/json”，然后单击“添加Webhook”**
注意：您可以选择要在Jenkins中接收的Webhook类型。例如，您只想在PR期间触发管道。然后，您可以从“让我选择单个事件”选项中仅选择PR事件。
您将在成功的 Webhook配置上看到一个绿色的勾号 ，如下所示。
如果您没有看到绿色的勾号或警告标志，请单击Webhook链接，然后单击最后一个Webhook。您应该能够使用状态代码查看为什么Webhook传递失败。
现在，我们完成了多分支管道的所有必需配置。下一步是测试多分支管道工作流触发器。
3.6 测试多分支管道¶
出于演示目的，我选择了“仅将分支作为PR的分支”选项。使用此选项，仅发现具有PR请求的分支。
要使用多分支管道，可以将此回购与示例Jenkinsfile一起使用。https://github.com/devopscube/multibranch-pipeline-demo
这个仓库有三个分支。更新功能分支中自述文件中的某些内容，并提高PR以进行开发。它将向Jenkins发送一个Webhook，并且Jenkins将发送回Jenkins的工作详细信息，并且PR将进入检查状态，如下所示。
如果单击“详细信息”，它将带您到Jenkins构建日志。您可以在您的Jenkins文件中编写自定义检查，以用于构建审核。
现在，如果您选择了Jenkins，您将在Jenkins中找到功能分支的管道，如下所示。
如果构建失败，则可以将更改提交到功能分支，并且只要PR打开，它将触发功能管线。
在Jenkinfile中，如果分支未开发，我添加了一个条件以跳过部署阶段。您可以在Jenkins构建日志中进行检查。另外，如果您在蓝海仪表板中检查构建流程，则可以清楚地看到跳过的部署阶段，如下所示。
现在合并功能分支PR并将新的PR从development提升到master分支。
Jenkins将收到来自Github的Webhook，以获取新的PR，并如下所示创建开发管道。
对于开发分支，启用了部署阶段，如果您检查了Blue Ocean的构建流程，则可以看到所有阶段都已成功触发。
3.7 对多分支管道进行故障排除¶
我将讨论在多分支管道中可能会遇到的一些错误，以及如何解决这些错误。
分支发现问题
有时，即使在SCM中创建了新分支之后，它也可能不会反映在Jenkins管道中。您可以尝试运行“立即扫描存储库”选项以再次扫描存储库。另外，检查管道中的存储库扫描配置。
Webhooks 不会触发管道
当Webhook没有触发管道时，请检查Github中的Webhook交付状态代码和错误。另外，请检查Jenkins URL是否正确。
还要从Manage Jenkins-> System Logs-> All Jenkins日志中检查Jenkins日志。如果Jenkins能够接收Webhook，则日志应显示未触发作业的原因。