jenkins任务失败重新构建插件Naginator Plugin jenkins任务经常会因为一些偶然因素失败,这时重新构建一次就肯能成功:jenkins的Naginator Plugin插件可以重新调度构建失败的任务:Retry Failed Builds Plugin也可以,但是已经过时不再更新了,建议用Naginator Plugin来替代. 1.插件下载地址 Naginator Plugin : https://wiki.jenkins-ci.org/display/JENKINS/N

1.展示这段shell命令 +详解 #===================================================================================== #=================================定义初始化变量====================================== #================================================================

SVN Publisher Plugin:https://wiki.jenkins-ci.org/display/JENKINS/SVN+Publisher 构建完成后的文件,比如Maven打的war包,可以通过SVN Publisher Plugin插件上次到指定的SVN,下面是收集的教程: http://blog.csdn.net/hemingwang0902/article/details/44488897 http://blog.csdn.net/qiaojiahe/article/de

这是一个基于消息的分布式事务的一部分,主要通过消息来实现,生产者把消息发到队列后,由消费方去执行剩下的逻辑,而当消费方处理失败后,我们需要进行重试,即为了最现数据的最终一致性,在rabbitmq里,它有消息重试和重试次数的配置,但当你配置之后,你的TTL达到 后,消息不能自动放入死信队列,所以这块需要手工处理一下. rabbitmq关于消息重试的配置 rabbitmq: host: xxx port: xxx username: xxx password: xxx virtual-host: x

问题: 把添加VPN的指令写在脚本里,然后用jenkins执行这个脚本,jenkins执行的结果是成功的,但是在机器上看,并没有执行成功.   问题分析: 其实在机器上执行过添加VPN的操作,只是在jenkins任务结束后,添加的VPN也自动跟着结束了,这个过程可以在执行的过程中做测试,使用sleep 1000的时候,然后去机器上看,确实是添加VPN成功的,但是jenkins执行的任务一旦结束,添加的VPN就消失了   解决办法:   在前面添加BUILD_ID=XXXXX,这样的话,jenki

前言 钉钉是我们日常工作的沟通工具,在Jenkins构建持续集成项目配合钉钉机器人的功能,可以让我们在持续集成测试环节快速接收到测试结果的消息推送. 一:新建一个钉钉群,选择自定义机器人 二:添加机器人,获取到access token 三:Jenkins安装dingding plugin插件 四:配置钉钉通知插件 五:在项目配置的 General 选项卡中找到 钉钉配置,勾选需要的机器人,通知人填写同事的手机号 六:查看效果

系统管理 1.进入系统管理-->系统设置 定位到Jenkins Location配置项   配置系统管理员邮件地址 系统管理员邮件地址需要同发送报警邮件地址相同 定位到邮件通知   配置SMTP服务器 例:smtp.qq.com   用户默认邮件后缀 例:@qq.com 可以不配置,没有影响   使用SMTP认证 此项配置需要开启,直接勾选即可.   用户名 发送邮件的用户名   密码 发送邮件的用户密码,需要注意的是如果是企业邮箱不需要通过授权可以直接使用账号密码的方式进行配置,如果非企业邮箱

首先我们需要确定我们的jenkins安装了:publish over ssh 插件,如果没有安装,到-->jenkins首页-->系统管理-->插件管理-->可选安装里面去搜 publish over ssh  -->然后获取即可 1.首先我们需要将jenkins服务器的公钥放到需要部署的服务器上,实现可以免密登陆, 2.到系统管理 --> 系统设置 --> 向下拉找到  publish over ssh 然后去配置 配置选项说明: 1.公共配置: Passphr

小白对jenkins运维的使用有点简单的想法,这里开个记录贴记录下. 由于未找到jenkins构建失败后执行其他脚本的插件,也暂时没有使用其他运维工具.所以想自己写一个shell脚本,一是方便其他人使用,二是可以失败后回滚. 本文使用gitlab webhook触发jenkins构建,jenkins执行shell命令--->mvn或者npm打包--->打包成docker镜像--->发布--->发布成功后用jenkins的git publisher插件push一个gitlab tag

持续集成之②:整合jenkins与代码质量管理平台Sonar并实现构建失败邮件通知 一:Sonar是什么?Sonar 是一个用于代码质量管理的开放平台,通过插件机制,Sonar 可以集成不同的测试工具,代码分析工具,以及持续集成工具.与持续集成工具(例如 Hudson/Jenkins 等)不同,Sonar 并不是简单地把不同的代码检查工具结果(例如FindBugs,PMD等)直接显示在Web页面上,而是通过不同的插件对这些结果进行再加工处理,通过量化的方式度量代码质量的变化,从而可以方便地对不同

因为官方文档上没有找到相关的说明,所以这里进行了例如以下測试,为了找到oracle数据库中 job 失败后重试时间的规律. 数据库版本号:11.2.0.3 測试说明:这里创建了一个日志表以及一个执行时必然出错的procedure,用于job的执行.这里仅仅要记录下每次job执行时视图user_jobs 中的 next_date就能够判断出job 执行失败后的重试规律. 为了測试job的重试规律我做了例如以下工作 日志表以及序列: create table job_exec_logs (id nu

前言: 我们在构建maven项目时,常常会用到一些特殊的jar包(不能在中央仓库中直接下载到本地仓库如微软不允许以maven的方式直接下载com.microsoft.sqlserver:sqljdbc4:jar:4.0等jar包),我们只能手动下载这部分jar包导入到maven本地仓库去引用.. 一个项目之前都能正常构建部署,今天开发改了pom文件,修改了一个本地jar包的引用方式,导致jenkins构建失败,再此记录 修改前的pom文件相关部分: 修改后的pom文件相关部分: 第一种引用方式j

背景:在Jenkins编译失败后,需要拿到Jenkins的编译失败的日志,存储在数据库中,在把数据取出来,在另外一个页面进行展示,我的思路为: 1.观看Jenkins编译失败后的控制台显示的内容 2.在查看网页源码,发现我们实际需要的内容是从<pre class="console-output"></pre>这里面的内容,那这样就很简单 3.编码 使用python的urllib headers = {"User-Agent": "M

最近在搞jenkins自动构建,遇到这样一个问题,我装的python相关的依赖在X用户下,但是jenkins在root下运行的,所以找不到相关的import 1. 执行pip freeze,会打印相关的依赖 2. 执行pip freeze > deploy.txt进行存储 3. su root进入root权限 4. pip install -r deploy.txt进行安装 这样就解决了jenkins构建失败的问题!

我的jenkins版本为Jenkins ver. 2.19.1 1.源码管理选项只有None的解决办法: 在插件管理中心,搜索对应的源码管理插件这里以git为例,搜索git plugin点击右下角的安装方式(在线安装需要连接VPN你懂的),如下图 重启后即可看到git按钮: 2.jenkins持续集成时,点击构建失败无法找到git.exe解决办法如下图: 控制台输出提示构建失败git.exe rev-parse --is-inside-work-tree # timeout=10:原因是没有找到

我们首先安装Jenkins邮件扩展插件“ Email Extension Plugin ”. Jenkins和插件的安装方法见上一篇文章:http://qicheng0211.blog.51cto.com/3958621/1918912 一.系统配置 1.进入Manage Jenkins->Configure System,找到配置段“Jenkins Location”: Jenkins URL :jenkins的访问地址 System Admin e-mail address :系统管理员邮件

问题的引出: 有一段我们的前端构建总会现git上分支名称中的版本号和工程里的版本号不一致的问题:这样会导致构一个问题:构建后的产品名称叫做1.1,但是进入app的关于页面,看到的版本还是1.0.这会让人很困惑,也会加大弄混被测物版本的风险. 最初,我们向开发提了这个问题,并且写了一份简要的说明文档贴在内部wiki上.结果发现效果并不理想,一部分开发会依照约定这么做,但是一部分开发不会这么做.由于多人多feature开发,这样的问题每2周就会出现一次,还很不好排查.维护Jenkins的小伙伴很郁闷

问题描述 同事在使用Jenkins打包项目的时候报错 error:index-pack died of signal 15 fatal: index-pack failed 出现这个问题,初步怀疑是拉取代码超时,为了验证这个问题,我分别在本地,jenkins服务器,其他服务器分别用git 拉取代码尝试,发现拉取代码的时候都是非常慢的,这个有可能和我们的代码仓在国外有关系. 后来在修改拉取代码时间后,构建还是失败. 通过在网上查阅资料,最终确认是git的http.postBuffer配置默认值大小

最近模块拆分,独立出了几个服务.上线流程并不复杂,只需要在指定目录执行bash deploy.sh master即可上线master分支.但是架不住模块太多,每天在上线流程上也花费了不少时间,所以尝试搭了个jenkins来自动化上线.上线时遇到了一个小坑,jenkins已经输出了启动成功的日志,但是实际上服务并没有跑起来,也就是说服务启动以后又被kill掉了.上网找了找资料,得出结论是jenkins杀掉了刚启动的服务. 服务被杀的原因是:jenkins默认会在构建完成后杀死构建过程中由jenki