持续集成高级篇之Jekins参数化构建(二)

系列目录

上一节我们讲解了如何使用bat脚本或者powershell脚本自身的机制来达到参数化构建的目的,这在一定程序上增加了灵活性,然而缺点也相当明显:它只能适应一些相对比较固定的参数传入(比如像上一节讲到的,构建的环境分为(developmentproduction)两种情况,对于一些相对较复杂的情况以上方法就会捉襟见肘,最为明显问题是外部的变化可能导致参数随之做必要更改,最常见的是文件的位置参数,我们指定归档文件的目录为D盘下的一个文件夹,现在D盘满了需要指定为其它盘,则所有的脚本都需要更改,这样的结果就是可维护性差.我们可以把一些较为常用的参数定义为全局参数,比如常用工具的位置.

本节我们将从项目级别,节点级别,全局级别来讲解Jenkins ci提供的参数配置方案

项目级别参数

本节部分我们分为参数构建和在项目中定义项目级别参数来讲解.

参数化构建项目.

在Jenkins里新建一个自由式项目,勾选This project is parameterized会出现一个Add Parameter按钮,点击会出现一个下拉框,选择最后一项‘string paramter‘创建一个字符串类型参数,在出现的对话框中输入名称(我用的是buildenv)和默认值(默认值可以不输入),在构建栏里我们选择Execute windows bat command,在出现的框中输入以下内容:

//buildenv为我们定义的参数名
echo %buildenv%

点击ok完成项目创建,此时build now按钮变成了Build with Parameters参数化构建,点击又会出现一步让输入值,有默认值可以直接点击‘build‘,点击后我们查看控制台可以看到输出了我们定义的参数

在以后的章节里也是一样,不管是Jenkins预置的参数还是我们自定义的,使用cmd时都是通过%参数名%来获取.

如果是powershell脚本,则需要使用$env:参数名来接收参数,比如在powershell命令窗口输入echo $env:buildenv就会达到和上面cmd一样的效果.

需要指出的是,如果在jenkins里直接执行powershell命令,需要下载powershell插件.

项目级别参数

以上参数化构建适用于需要手动构建的,不是特别频繁但是参数又必须动态指定的情况,这种构建缺点也相当明显,因为每次需要手动指定参数.还有一种方法是指定项目级别的参数,这种方式比直接使用脚本自身参数要更容易管理,因为参数在单独的一块地方定义,并且可以添加描述,使得语义更加明确,并且参数在单独醒目地方出更容易引起关注.

下面讲解一下如何在项目级别添加环境变量.

新建一个自由式项目,名称随意,找到Build Environment栏目,找到Inject environment variables to the build process选项并勾选,此时会出现一些输入框让输入,Properties File Path暂时忽略,在下面的Properties Content里输入buildenv=development就可以在bat,shell或者powershell脚本里使用它了.

如果需要定义多个参数,换一行书写就行了,同样是name=value形式

大家可能已经看到,选项里除了Properties Content外,下面还有Groovy Script选项,大家不要害怕,这里并不讲Groovy,这里可以使用一些简单的groovy语法来定义参数变量

Groovy Script框里输入的选项如下

def str="hello,world"
return ["greeting":str,"filename":"jenkins.txt"]

可以使用 def关键字定义一个变量,下面return里的内容可以做为参数在构建时使用.比如在bat脚本里可以使用%greeting%来获取键为greeting的参数的值.

节点级别参数

有些参数在不同的节点上是不一样的,比如说某一个工具的位置,如果我们把它定义为项目级别,由工具在不同节点上安装的位置可能是不一样的,这样就会造成部分节点上的构建失败.这时候可以考虑把参数定义为节点级别.

进入Manage Jenkins>Manage Nodes,进入管理页面便会看到我们已经创建好的Jenkins节点,点击某个基点后面的齿轮图标,在出现的界面里找到Node Properties,勾选Environment variables此时便可以输入参数的名称和值,点击Add按钮则可以添加多个参数.完成后点击Save保存后便可以在脚本里使用刚定义的节点级别的变量了.

全局变量

全局变量对所有节点都有效,当某些变量不会因为环境的改变而改变,比如说构建的版本只有development和production时,就可以定义为全局变量.这样不需要在每个项目里都重复定义了.

全局变量的定义也非常简单,进入Manage Jenkins>Configure System找到Global properties并勾选Environment variables出现的界面跟节点级别配置类似.

使用文件参数

Jenkins提供了灵活的配置选项,我们除了可以在Jenkins内部配置参数外,还可以以外部文件的形式提供配置参数,配置参数为name=value键值对形式,必须符合java properties文件格式.

下面讲解如何使用配置文件.

我们新建一个自由式项目,滚动到Build Environment栏,勾选Inject environment variables to the build process,在Properties File Path选项里输入配置文件路径,我放在了E盘里,路径为E:\testenv.txt,这个文件很简单,里面就一行内容,如下:

database=sqlserver

往下流动到Build栏,新建一个 Execute windows bat command,输入以下内容

echo %database%

保存后点击构建,可以看到控制台输入sqlserver

原文地址:https://www.cnblogs.com/tylerzhou/p/11427566.html

时间: 2024-07-28 23:37:54

持续集成高级篇之Jekins参数化构建(二)的相关文章

持续集成高级篇之Jekins参数传入与常见任务

系列目录 有的童鞋可能已经发现,PipeLine项目与自由式项目相比,可配置的项少了很多,比如说环境变量定义,所有步骤完成后执行动作,拉git代码库等.其实这些功能并没有缺,而是配置的方式不一样了,以前是通过图形化界面配置,虽然直观简便,但是功能不能包罗万像,对于一些复杂的项目显得捉襟见肘,而Jenkins PipeLine使用代码配置功能更加强大.以后的章节中我们会介绍常用的配置如何通过PipeLine里的Groovy脚本来实现. 前面讲参数化构建的时候已经讲到对于复杂的构建把一些重复的,常用

持续集成高级篇之Jenkins Pipeline 集成sonarqube

系列目录 前面章节中我们讲到了Sonarqube的使用,其实Sonarqube获取msbuild结果主要是执行三个命令,开始标记,执行msbuild,结束标记,这些都是命令,是非常容易集成到我们ci流程中的,但是使用这种方式最为简单,但是Sonarqube插件与jenkins集成的更好,我们可以通过jenkins页面看到构建结果是否成功,以及可以通过链接轻松地跳到Sonarqube web管理界面.前面章节我们介绍了如何在自由式任务中使用sonarqube插件,这里我们讲下如何在pipeline

持续集成高级篇之基于win32-openssh搭建jenkins混合集群(一)

系列目录 前面的demo我们使用的都是只有一个windows主节点的的jenkins,实际生产环境中,一个节点往往是不能满足需求的.比如,.net项目要使用windows节点构建,java项目如果部署在linux服务器上往往也需要目标类型的linux节点做为构建节点,开发中使用的jdk版本不同也可能需要不同的构建主机.构建docker镜像往往也需要linux主机(强烈不建议使用docker for windows 进行linux环境的docker构建).本节我们讲解如何搭建一个主节点为windo

持续集成高级篇之Jenkins cli与Jenkins ssh

系列目录 Jenkins Cli介绍 Jenkins Cli为Jenkins提供的一个cli工具,此工具功能非常强大,可以完成诸如重启jenkins,创建/删除job,查看job控制台输出,添加/删除节点等功能.但是实际工作中,像创建任务这样的配置显然cli非常吃力,不如直接在web管理界面操作,但是对于重启Jenkins,查看诊断信息等,执行一个手动构建任务等,则直接使用cli比进入web管理界面操作更加方便.因此什么时候web管理界面,什么时候使用cli,要看是否有利于提升生产力,是否有利于

持续集成高级篇之Jenkins Pipeline git拉取

系列目录 PipeLine中拉取远程git仓库 前面讲自由式任务的时候,我们可以看到通过自由式job里提供的图形界面配置git拉取非常方便的,实际上使用PipeLine也并不复杂.这一节我们展示一下如何在PipeLine任务中拉取git仓库代码. node{ stage("check out"){ git credentialsId: '3c210def-c000-4e2a-9b2d-838986a6b172', url: 'https://github.com/mrtylerzhou

IOS使用jenkins进行持续集成 第二篇

上一篇,自己尝试进行持续集成,研究的不深入,这两天,为公司搭建持续集成环境,以及内部发布系统,了解的更多了,所以分享出来. 这篇主要介绍一些其他东西,不重复介绍上一篇的内容. 如果使用jenkins进行ios持续集成,需要xcode插件支持,所以先下载xcode插件,而且后期还要用到ftp服务,也安装ftp的插件. jenkins中可以自己创建特定的视图分组,all视图点击+号就能创建新视图,创建好后,在左侧的编辑视图选项,则会进入详情页,可以选择放入此视图的任务:相对于任务,我觉得最好依据代码

IOS使用jenkins进行持续集成 第一篇

本文主要讲述在开发过程中,提高工作效率而进行的IOS-Jenkins的持续集成. 背景 平时我们开发完成IOS项目,需要打包给测试人员进行测试.其中的过程需要重复进行:修改配置项--编译---连接设备--运行打包--debug进设备中--然后交给等待的测试人员.现有成熟的持续集成Jenkins解决方案,并且该方案也提供了Xcode插件的支持,可以讲上述过程封装成一键解决方案. 我实现的是jenkins执行IOS的job,build工程,签名打ipa包,上传到FTP服务器,放到tomcat下,提供

.net持续集成sonarqube篇之 sonarqube触发webhook

系列目录 WebHook近些年来变得越来越流行,github,gitlab等代码托管平台都提供webhook功能.关于webhook这里不做详细介绍,大家可以参阅读相关互联网书籍或者材料来更深了解.可以把它简单理解为某一事件完成以后的一个回调. 在持续集成环境里,我们可以使用Sonarqube的webhook功能来实现持续发布和发布包归档功能.大致思路是当项目构建成功后我们可以通过webhook通知服务器构建任务已完成,接下来web 服务器可以根据webhook传递的参数决定要处理的包是哪个项目

持续集成:API自动化 + Jenkins定时构建

系统管理1. 管理监控配置 系统管理>>系统设置>>管理监控配置 2. 设置接收测试报告的邮箱 系统管理>>系统设置> >配置Extended E-mail Notification   邮件标题即正文代码:邮件标题: 自动化测试项目:$PROJECT_NAME - 构建结果:$BUILD_STATUS 邮件正文: <!DOCTYPE html> <html> <head> <meta charset="U