Jenkins Build Radiators(构建发射源)

information radiators(信息发射源)的概念通常被用在敏捷的圈子里。

据敏捷专家Alistair Cockburn所说:

一个信息发射源是一个贴在一个地方的显示器,当人们工作或路过时能够看到它。

它给读者展示他们关系的信息而不用问别人一个问题。

这意味着更多的交流和更少的打断。

在一个CI服务器的环境中,一个信息发射源是一个突出的设备或显示器,允许团队成员或其他人易于看到是否是否任何构建当前中断了。

它通常展示或者所有当前构建结果的摘要,或者仅仅是失败的构建结果的摘要,并且展示在一个大的、突出的固定在墙上的平面屏幕上。

这种特定的信息发射源通常被称为构建发射源(build radiator)。

当使用得当时,构建发射源是最有效的被动通知策略。它们非常有效的确保每个人都知道失败的构建。

构建发射源能够满足许多构建任务(build jobs)的需要,包括许多失败的构建工作(failing buildjobs),因此能够有效的被使用在多个团队的环境。

对Jenkins来说有几个构建发射源(build radiator)解决方案。

最易于使用的是Jenkins Radiator View plugin,这个插件添加了你可以创建的一种新类型的View,如下图:

配置build radiator view与配置传统的list view非常类似——你仅仅需要指定你想包含在View中的构建Job即可,单独的或者使用正则式选择它们。

因为build radiator view占据了整个屏幕,修改或者删除一个build radiator有点棘手。

实际上,打开view配置的惟一方式是在view的URL后面追加/configure:

所以,如果你的build radiator被叫做“build-radiator”,你可以通过打开http://my.hudson.server/view/build-radiator/configure来编辑view的配置。

build radiator view为每个失败的(failing)或者不稳定(unstable)的构建显示一个大的红色的或黄色的盒子。

构建job的名称以及其他详情显示在突出的信件中。

你可以配置build radiator view显示通过的构建(passing builds),和显示失败的构建一样,(通过的构建将被显示在小的绿色的盒子中)。

不过一个好的build radiator真的应该只显示失败的构建(failing builds),除非所有的构建是通过的。

参考:

http://guide.agilealliance.org/guide/information-radiator.html

https://www.safaribooksonline.com/library/view/jenkins-the-definitive/9781449311155/ch08s06.html

https://wiki.jenkins-ci.org/display/JENKINS/Radiator+View+Plugin

时间: 2024-08-30 04:19:30

Jenkins Build Radiators(构建发射源)的相关文章

Bitbucket 触发内网 Jenkins Build

为了保证安全性多数的持续集成系统都会部署在公司内部的局域网中,这样如果代码部署在 Bitbucket 等环境中就只能通过轮询的方式来触发 Build.那么有没有办法通过 Bitbucket 的 Webhooks 功能在开发人员提交代码时触发 Build 呢?答案是肯定的,并且有很多种实现方式.本文笔者将介绍一种比较简单的实现方式来实现由 Bitbucket 的 Webhooks 触发内网 Jenkins 中的 Build.其结构如下: 实现本方案的条件是需要在外网有一台可以访问的主机,通过 SS

Jenkins通过maven构建编译JAVA项目

Jenkins 通过maven 构建编译 JAVA 项目环境 官网下载合适Jenkins版本包: jenkins http://mirrors.jenkins.io/war-stable/  Jdk curl -L -O http://download.oracle.com/otn-pub/java/jdk/8u45-b14/jdk-8u45-linux-x64.tar.gz  JDK SE http://120.52.72.24/download.oracle.com/c3pr90ntc0td

基于Jenkins的自动构建系统开发_android总结

持续集成相关理论 1.1 极限编程的概述 1.1.1 极限编程的产生 2001年,为了解决许多公司的软件团队陷入不断增长的过程泥潭,一批业界专家一起概括出了一些可以让软件开发团队具有快速工作.响应变化能力的价值观和原则,他们称自己为敏捷联盟.敏捷开发过程的方法很多,主要有:SCRUM,Crystal,特征驱动软件开发(Feature Driven Development,简称FDD),自适应软件开发(Adaptive Software Development,简称ASD),以及最重要的极限编程(

Jenkins pipeline自动化构建审批功能

Jenkins Pipeline是一套插件,支持将连续输送Pipeline实施和整合到Jenkins.Pipeline提供了一组可扩展的工具,用于通过PipelineDSL为代码创建简单到复杂的传送Pipeline. 对于单个项目来说,使用这样的Pipeline来构建能够满足绝大部分需求,但是这样做也有很多缺陷,包括: 多个项目的Pipeline打包脚本不能公用,导致一个项目写一份脚本,维护比较麻烦.Jenkins提供了一个更优雅的管理Pipeline脚本的方式,在配置项目Pipeline的时候

Docker+Jenkins+Gogs 自动构建.Net Core

Docker+Jenkins+Gogs 自动构建.Net Core 引言 jenkins+gags 全部采用Docker安装,通过jenkins插件ssh调用外部Docker构建 主要实现功能: git代码提交至Gogs,Jenkins自动构建至Docker 必要条件 1.Centos 7 2.Docker(题主18.06.1-ce) 3.Dot Net Core(2.1.4 ) .Net Core世界第一??不接受反驳?? ?? 安装Jinkins 镜像传送门 https://hub.dock

Jenkins的分布式构建及部署——节点

一 什么是Jenkins的分布式构建和部署 Jenkins的分布式构建,在Jenkins的配置中叫做节点,分布式构建能够让同一套代码或项目在不同的环境(如:Windows和Linux系统)中编译.部署等. 二 什么时候使用节点和作用 当我们使用多台服务器时,并且配置了tomcat或jboss集群服务,可通过jenkins的节点配置,将jenkins项目发布在不同服务器上(分布jenkins工作空间,部署项目到不同服务器的tomcat或jboss),这就形成了jenkins的分布式.节点服务器不需

如何用jenkins实现自动化构建新版本和二维码下载

最近公司开发了自己的app,研发过程中对于测试人员来说,经常会像开发的人员询问,有没有最新的包啊(apk打包后的新版本),以免你测试的时候,提交了一些缺陷,实际上人家已经解决了.当然你也可以说你们公司开发流程也太乱了.发布新版本不是应该按时,按计划的执行测试么. 实际情况确实是一天多个版本 或者好几天给一个版本.(敏捷测试推行,但是推行的不是很到位时候就这样) 这就有了一个痛点,我们测试人员能不能直接打包apk,并且把保持每天的版本都是最新的. 以安卓版本为例,ios,暂没成功配置. 需求是我们

Jenkins build 后 tomcat 启不来

Jenkins build 后 war 包复制到 tomcat 下,启不来 添加 :export BUILD_ID=dontKillMe /usr/local/iron/tomcat8085/bin/shutdown.sh rm -r -f /usr/local/iron/tomcat8085/webapps/audit* cp -f /var/lib/jenkins/workspace/CPA-Service/Service/air-ws-jkwsk/target/audit.war /usr

jenkins +git+ssh 构建 .net项目

jenkins +git+ssh 构建 .net项目 安装jenkins jdk 和插件就不一一介绍了. Multiple SCMs 插件介绍:可以获取多个项目(如果你的项目中有依赖其他项目的) Source files :需要上传的文件地址,相对地址(比如:D:\Program Files\Jenkins\workspace\test\a.zip:对应这里a.zip,test为当前构建的项目) Remote prefix:忽略前面的路径(比如:test:远程服务器上就是a.zip) Remot