https://jenkins-zh.github.io/ Recent content on Jenkins 中文社区 Hugo -- gohugo.io zh-CN Wed, 10 Apr 2019 00:00:00 +0000 https://jenkins-zh.github.io/about/code-of-conduct/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/about/code-of-conduct/ 留言 留言之前需要使用 GitHub 账号登陆。大家要注意文明用语，严禁攻击、诋毁、灌水、广告等无关的话。对于违反人，一经发现将会被拉入黑名单。 提问 欢迎每一位朋友在这里提出与 Jenkins 或相关领域的技术问题，但是，在提问之前建议先在搜索引擎和本站中进行搜索。 问题至少要包含如下部分： 场景以及问题是如何发生的，方便阅读的人复现 软件、环境相关版本信息 日志、截图等（建议使用附件的方式） 出于对回答问题者的尊重，请得到解决方案后及时表示感谢，或者从其他地方得到答案后添加相关链接以及说明。 GitHub 请您使用同一个 GitHub 账号来与大家交流，不欢迎使用所谓的“小号”。 https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-10-getting-started-with-docker-for-java-applications/ Wed, 10 Apr 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-10-getting-started-with-docker-for-java-applications/ Docker 已经非常出名并且更多的组织正在转向基于 Docker 的应用开发和部署。这里有一个关于如何容器化现有 Java Web 应用以及使用 Jenkins 为它建立一个端到端部署流水线的快速指南。 为此我使用了非常著名的基于 Spring 的宠物商店应用，它代表了一个很好的示例，因为大多数应用都遵循类似的体系结构。 步骤 构建宠物商店应用。 运行一次 Sonar 质量检查。 使用该 Web 应用准备 Docker 镜像。 运行容器以及执行集成测试。 如果所有测试成功，推送该镜像到一个 dockerhub 账户。 所有的代码都在这里。 这里是可用于以上步骤的 Jenkins 流水线代码： node { stage 'checkout' git 'https://gitlab.com/RavisankarCts/hello-world.git' stage 'build' sh 'mvn clean install' stage('Results - 1') { junit '**/target/surefire-reports/TEST-*.xml' archive 'target/*.jar' } stage 'bake image' docker.withRegistry('https://registry.hub.docker.com','docker-hub-credentials') { def image = docker.build("ravisankar/ravisankardevops:${env.BUILD_TAG}",'.') stage 'test image' image.withRun('-p 8888:8888') {springboot -> sh 'while ! https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-08-becoming-contributor-intro/ Mon, 08 Apr 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-08-becoming-contributor-intro/ 作为一名软件工程师，这些年来在我工作过的不同公司里用到过许多开源软件（包括框架、库、工具等）。 然而，在此之前我从没有以一名贡献者的身份参与过开源项目。 自从我向 Jenkins 提交第一个简单又滑稽的 commit 已经过去六个月（2018 年 9 月）了， 我也尝试过作出更多贡献。然而总的来说，向开源项目贡献代码是具有挑战的， 特别是像 Jenkins 这样有着很长生命周期的项目，项目中不乏遗留代码和系统知识。 它通常难以入手，也很难想到一个计划来持续贡献使你的付出从长远看来是有意义的。 对于 Jenkins 社区来说，我在尝试加入社区时所遇到的困难是其它人也有可能会面临的， 因此我决定分享我成为 Jenkins 活跃贡献者的心路历程。 我计划大概每月发布一篇博文来描述我的这段旅程，我将从简单容易入手的项目开始， 随着时间推移再介绍更加复杂的项目。 从哪开始 jenkins.io 要成为 Jenkins 的贡献者，首先会看到的就是 jenkins.io, 在顶部导航中”社区”下拉列表里第一个”参与”的链接就能将我们带到”参与和贡献”这个页面。 在这个页面中列举了我们能够参与 Jenkins 项目和社区的许多方式。尽管它展示了所有可能的选项供读者选择，但一下子看上去令人有些无所适从。 这个页面被分成了左右两个部分，左边提供了参与社区的方法，右边是向社区贡献的方法。 参与社区的建议 在“参与和贡献”页面的左侧是有关参与社区的建议，其中包括结交他人、审阅修改或者提供反馈信息。 这里面最让我困惑的是沟通渠道，里面列出的沟通渠道有 几个邮件列表 还有 IRC 和 Gitter 频道。 当我第一次尝试参与时，我订阅了许多邮件列表和几个 IRC 和 Gitter 频道，但我很快发现里面有重要的讨论正在进行， 并且活跃的讨论中多数是关于特定的用户或开发者的问题。因此，我不建议你一开始在这上面花太多时间， 除非你是要为其他用户提供帮助（当你是经验丰富的 Jenkins 用户时可能会有这种情况）或者你已经有一个明确的问题需要提问。 看一看社区成员如何互相帮助是好事，但是对新人来说它的信息量过于庞大。如果你的兴趣在于向 Jenkins 项目作贡献（不管是翻译、文档还是代码）， 这些对话不会对你有太大的帮助。 向社区贡献的建议 在“参与和贡献”页面的右侧有一些关于如何贡献的建议，主要分为：编写代码，翻译，文档和测试。 在之后的博客中，我将介绍所有的这些贡献类型，以及如何参与的建议包括如何审阅 Pull Requests（PRs）或提供反馈 （反馈问题或者复现其它用户反映过的问题，提供额外信息来帮助维护者复现和修复它们。） 开源之旅的第一次贡献 当看到「参与和贡献」页面时，我发现我可以帮助改进这个页面的一些内容。本来我打算选择其中一个作为这篇文章的第一个例子，但当我阅读贡献指南时， 我发现了一个更简单的贡献。我认为它可以更好的说明开始贡献社区是多么的简单，于是我决定就用它来当例子。 网站代码仓库 在「文档」菜单中有一个链接 jenkins.io 的贡献指南， 这个 CONTRIBUTING 文件是大多数开源项目代码仓库的根目录中都会有的常见文件。 https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-03-the-benefits-and-challenges-of-continuous-integration/ Wed, 03 Apr 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-03-the-benefits-and-challenges-of-continuous-integration/ 毫无疑问，持续集成（ CI ）已成为一个软件开发的主流原则。CI 的收益在业界众所周知的，并且很难找到反对实施它的人。 在这里，我想把那些收益收集起来放到一个中心化的地方。但是我认为扮演反面角色并试图找出持续集成的弊端或挑战也是很有趣的。 什么是持续集成？ 从根本上说， 持续集成（ CI ）是一种开发实践，开发人员每天都要将代码集成到共享的仓库中。在该仓库中，代码被自动构建进行验证用来在这个流程中检验尽早的发现任何问题。这允许团队花更少的时间回溯，而花更多的时间构建新特性。 持续集成的收益 1、缓解风险 据 Martin Fowler 说，持续集成的最大收益是减轻风险。由于延迟了代码集成，团队将不断增加合并冲突的数量和严重性。当团队频繁集成（使用自动构建），他们减轻了潜在风险的数量，因为他们总是知道系统的当前状态。 2、质量保证 实施持续集成的团队对他们的操作更有信心。他们知道自动构建会立即捕获缺陷，这使他们能够保证质量。 他们也不会猜测系统中 bug 的数量，这允许他们能够向队友提供准确的数量，并为客户提供更好的服务。 3、提高可见性和加强团队合作 自动构建为团队提供了对其系统的完全可见性。他们知道问题的数量，并能快速的解决问题。提高可见性可以让团队有机会在小问题变成大之前通过协作解决。 持续集成的挑战 1、组织文化变革 一些企业更喜欢传统的方法，并且可能很难实施持续集成。 他们必须对员工进行再培训，这就意味着要对现有的业务进行大修。管理者可能会抵制因为持续集成并不能帮助他们实现公司的直接目标（例如：金钱在质量之上）。 2、难以维护 构建一个自动化的代码仓库不是一个简单的任务。 团队必须构建适当的测试套件，并花时间编写测试用例，而不是开发代码。 起初，这可能会让他们放慢速度，让他们对按时完成自己的项目失去信心。如果测试套件不稳定，它可能在某些天内完美地工作，但其他天可能不起作用。 然后团队将不得不花费更多的时间来弄清楚发生了什么。 3、大量的错误信息 对于较大的开发团队，他们可能每天都会看到 CI 错误消息，并开始忽略它们，因为它们还有其他任务和关注点。 他们可能会开始将一个破坏的构建视为一个正常的事情，并且缺陷可能开始堆积在一起。 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-18-weekly-version/ Wed, 20 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-18-weekly-version/ Jenkins LTS 2.164.1 更新内容如下： Java 11 现已全面支持。 自 2.150.x 开始在 Java 11 上运行 Jenkins 的多项改进，包括：支持插件在它们的元数据中申明最小 Java 版本，并拒绝加载不兼容的插件，以及当运行在 Java11 上时安装新的 JAXB 插件后允许使用 JAXB 的 API. (博客发布的申明, 运行在 Java 11, 升级到 Java 11, issue 52012, issue 52282, issue 55076, issue 55048, issue 55980, issue 55681, issue 52285) 当列出一个指定目录时 list-jobs 不再进行递归。 (issue 48220) 增加一个新的 CLI 命令 disable-plugin 来禁用一个或多个已安装的插件，并可以选择同时重启 Jenkins. (issue 27177) 更新 Trilead SSH 库以支持 OpenSSH 使用 AES256-CTR 加密。 (issue 47603, issue 47458, issue 55133, issue 53653) 在 Jenkins CLI 中增加对 ed25519 关键算法的支持。 (issue 45318) 减少以 ZIP 格式下载归档或者工作空间文件时 SECURITY-904 对性能的影响。 (issue 55050) 在插件向导中增加语言分类，并会根据浏览器的语言设置自动安装本地化插件。 (pull 3626) Windows Service Wrapper 从 2. https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-20-cdf-launch/ Wed, 20 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-20-cdf-launch/ 今天Linux 基金会与 CloudBees、Google 和一些其他公司启动了一个新的开源软件基金会，也就是持续交付基金会(CDF). CDF 相信持续交付的力量，它旨在培养与支持开源生态，以及厂商中立的项目。 Jenkins 的贡献者们已经决定，我们的项目应该加入这个新的基金会。 实际上，这样的讨论持续了多年，大致的动机简洁摘要在这里。 此时，作为一名用户，又意味着什么呢？ 首先，不会有大的中断。还是同样的人，URL 地址不会变，也会有正常的发布。决策方式也会延续，pull request 也不会发生变化。改变会逐步的进行。 这是 Jenkins 项目在这个领域的成熟和重要性的又一证明。在全球有25万个 Jenkins 在运行着，这着实从 IoT 到游戏、从云原生应用到机器学习项目撼动着整个软件研发的世界。对于任何寻求开放异构 DevOps 策略的人来说， Jenkins 是一个显然、安全的选择。 CDF 创建了一个公平竞争的环境，这被组织中的贡献者所熟知，同时也会带来更多的贡献者，让 Jenkins 发展的更好、更快。在过去的几年里， Jenkins 项目正在稳步地增长，更多的结构使之变得清晰起来，CDF 是这一轨迹中的最新一步。 任何认真的研发团队都会把多种工具和服务结合起来，以覆盖整个软件研发领域。这些团队为了把这些工具集成起来投入了大量的工作。 Jenkins 将会在 CDF 旗下与其他项目紧密合作，使得这些软件之间减少重复。 我们的用户作为从业者尝试在他们的组织中改善软件研发流程。他们认为 CI/CD 和自动化可以释放组织所需要的生产力，但对他们的组织而言，并不总是那么显著。因此，我们的用户往往无法得到必要的支持。CDF 将会倡导持续交付的实践，因为这并不是来自某个厂商或项目，它将会联系可以提供帮助的人。 因此，我希望你能明白为什么我们会对此感到如此兴奋！ 实际上，对我们来说，已经为这个想法努力了将近两年。毫不夸张地说，整个 CDF 的想法 源自 Jenkins 项目。 为此，已经有很多人在幕后做了大量的工作。但有些人扮演了举足轻重的角色，我须亲自感谢他们。为 Chris Aniszczyk 的耐心、坚持，R. Tyler Croy 酝酿并推动着这个想法，Tracy Miranda 将这些想法变成事实。 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-electron-pipeline-demo/ Wed, 13 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-electron-pipeline-demo/ 面向读者：需要了解 Jenkins 流水线的基本语法。 Electron 是由 Github 开发，用 HTML，CSS 和 JavaScript 来构建跨平台桌面应用程序的一个开源库。 本文将介绍 Electron 桌面应用的流水线的设计。 但是如何介绍呢？倒是个大问题。笔者尝试直接贴代码，在代码注释中讲解。这是一次尝试，希望得到你的反馈。 完整代码 pipeline { // 我们决定每一个阶段指定 agent，所以， // 流水线的 agent 设置为 none，这样不会占用 agent agent none // 指定整条流水线的环境变量 environment { APP_VERSION = "" APP_NAME = "electron-webpack-quick-start" } stages { stage("生成版本号"){ agent {label "linux" } steps{ script{ APP_VERSION = generateVersion("1.0.0") echo "version is ${APP_VERSION}" }} } stage('并行构建') { // 快速失败，只要其中一个平台构建失败， // 整次构建算失败 failFast true // parallel 闭包内的阶段将并行执行 parallel { stage('Windows平台下构建') { agent {label "windows && nodejs" } steps { echo "${APP_VERSION}" } } stage('Linux平台下构建') { agent {label "linux && nodejs" } // 不同平台可能存在不同的环境变量 // environment 支持阶段级的环境变量 environment{ SUFFIX = "tar. https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-gsoc2019-announcement/ Wed, 13 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-gsoc2019-announcement/ 作为 Jenkins GSoC 管理员团队的代表，我很高兴地宣布 Jenkins 在2019年的 Google Summer of Code上 已经被接受。 今年，我们邀请了学生和导师加入 Jenkins 社区，并一起努力增强 Jenkins 生态圈。 这里提供一些数字，这是有史以来最大的一次 GSoC，今年共有206个组织参与。并且，希望对 Jenkins 而言也是最大的一年。 我们有25个项目想法，而且有超过30个准导师（不断增多！）。 这已经超过了2016年以及2018年的总和。 有很多的插件，特别兴趣小组以及子项目已经加入了今年的 GSoC.而且，我们已经收到了十几个学生的消息以及第一次贡献，耶！ 下一步？ GSoC 已经正式启动，请期待更多的学生在我们的Gitter 频道和邮件列表中联系项目。 在特别兴趣小组和子项目频道中已经有了很多沟通。 我们会努力帮助学生找到他们感兴趣的项目，在这个领域探索，并帮助他们在4月9日的截止日前准备好他们的项目提议。 然后，我们将会继续这个申请，选择项目并分配导师团队。 所有关于 Jenkins GSoC 的信息都可以在子项目页面上找到。 我是一个学生。如何申请？ 在/projects/gsoc/students[学生的信息]页面中有完整的申请指导。 我们鼓励感兴趣的学生尽早联系 Jenkins 社区并开始探索项目。所有的项目在对应的页面上都有聊天室与邮件列表。 我们也会为学生组织工作日的会议，在这些会议上你可以见到管理员和导师，并向他们提问。 另外，加入我们的Gitter 频道和邮件列表，以便收到项目中即将到来的事情。 3月25日开放申请，但你现在就可以准备了！利用这段申请前的时间来讨论并改进你的项目提议。 我们也建议你着手熟悉 Jenkins 并开始探索你的提议的领域。项目的想法包括快速开始的指导，以及有助于初期研究时对新手友好的问题。 如果没有看到任何感兴趣的，你可以提出你自己的项目想法或者 查看由其他参与 GSoC 的组织提出的想法。 我想要成为一名导师。会不会太晚了？ 不晚！我们正在寻找更多的项目想法，以及 Jenkins 的贡献者或用户中对 Jenkins 富有热情并想要指导学生的人。 无须底层经验，导师可以和学生一起研究项目并给出技术指导。 我们尤其对 Java 技术栈方向感兴趣，以及一些新的技术和领域（例如：Kubernetes, IoT, Python, Go 或者其他的）。 你可以提议一个新项目或者加入已有的。查看博客寻找导师以及导师的信息中的细节。 如果你想要提议一个新项目，那么请在3月11日之前完成，以便学生有时间探索并准备他们的提议。 今年，导师并不必须要有 Jenkins 开发上的很强的专业知识。目标是指导学生参与到 Jenkins 社区。 如果需要特殊的专业知识，GSoC 组织管理员会帮助寻找顾问。 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-ready-for-cdf/ Wed, 13 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-ready-for-cdf/ 大概十一年前，我就开始为现在被称为 Jenkins 的项目做贡献，自己当时其实也并不知道在做什么。但是接下来发生的事情令人感觉难以置信，数以百计的贡献者加入，成千上万的新用户开始使用 Jenkins，每天都会运行数以百万条的流水线。这样的增长是充满挑战性的，用户的增长意味着问题的增长，问题的增长就意味着需要新的解决方式。 在大约两年半之前，我在2017年的 Jenkins World Contributor Summit 大会上面对一大群 Jenkins 的贡献者们，为我的所谓的 ‘Jenkins软件基金会’ 做了宣传，那就是，不要羞于从 Python 社区汲取思想，在我的朋友 Chris Aniszczyk 和 Linux 基金会的帮助下，这个基金会变成了一个更加全面的 *持续交付基金会*（CDF），我的同事 Tracy Miranda 一直在领导这项工作，帮助推动 CDF 的成立。 Kohsuke 为 jenkinsci-dev@ mailing list 撰写了一篇很好的概述文章，其中列举了如果 Jenkins 项目一旦建立后就应该加入 Continuous Delivery Foundation 的原因。如果你对 Jenkins 项目感兴趣，但是还没有阅读过这边文章的话，那我认为你应该花些时间来阅读 Kohsuke 的这份邮件。但是在 这篇文章 中，我 想分享我愿意帮助建立持续交付基金会（CDF）的原因。 持续交付（CD）已经成为我职业生涯中不可或缺的一部分，甚至在 Jez Humble 将此概念清晰地表述之前，我就开始学习 CD 并且对它一直充满热情。我认为它对软件的开发实践至关重要，当有人说他们没有练习使用 CI 或 CD 时，我感觉这就像回到了原始社会。想象一下，如果有人说 “呃，我们在这里有一个采用 Source Control 的项目，但领导们觉得这个东西不太靠谱”，我想你肯定会惊掉下巴。”在这个时代竟然还有开发团队都不使用源代码管理？”。总体来说，我认为CD已经是现代软件开发的基础了。 持续交付也 不是 说只依赖于 Jenkins 这样的单一工具，它也是依赖于其他的用于协同工作的许多工具。虽然我可能觉得 Jenkins 是所有工具中占最中心位置的工具，但也不是说 Jenkins 是这些工具中唯一优秀的一款工具。但是不幸的是，像 Jenkins 这样的许多开源社区往往对他们的世界有着一定的狭隘观点。他们只专注于他们的事情，虽然这是有道理的，但这及可能导致错失交叉合作产生新价值的机会。 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-01-08-mpl-modular-pipeline-library/ Wed, 06 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/03/2019-01-08-mpl-modular-pipeline-library/ MPL - 模块化的流水线库 尽管通过自动化部署加快了开发速度，但由于在 DevOps 方面缺少协作，我们一个客户正因此而放慢产品的上市时间。虽然他们也投入了资源来做 DevOps ，但每条生产流水线都是独立设置的，迫使团队为每个项目重新造轮子。更糟糕的是，由于没有跨团队协作，平台中的任何错误又会出现在每条新的流水线中。许多客户都有类似的问题存在，因此我们决定开发一个既能帮助现有客户，又能适应未来使用需求的通用工具。使用通用框架且标准化的 CI/CD 平台是最显而易见的选择，但这将导致缺少灵活性的单体结构（monolithic structure），最终会变得举步维艰。每个团队都需要在自己的流水线上工作，基于此，我们开发了一个方便 DevOps 流水线的每个可重用部分可供以后使用的解决方案 — Jenkins 驱动的模块化流水线库。 解决方案：模块化流水线库 模块化流水线库（译注：modular pipeline library，简称 MPL）是一个高度灵活的 Jenkins 流水线共享库，它可以轻松将最佳实践共享到整个公司。它具有清晰的模块化结构，先进的测试框架，多级嵌套的能力，流水线配置系统，被改进了的错误处理机制以及许多其他有用的组件。 我们将通过以下几部分内容深入了解并解释 MPL 是如何工作的： 探索用于构建 MPL 的技术和工具 回顾MPL，并说明它为何有效 一步一步在流水线样例中使用 MPL 深入研究 MPL 的一些重要的组件，例如测试框架和嵌套库 首先，让我们介绍构建 MPL 时使用到的关键技术。 使用共享库和 Jenkins 流水线构建 MPL 我们的 Jenkins 自动化平台最近收到了一些 Jenkins 流水线的更新。这些更新允许我们创建一个 Jenkinsfile 文件来描述整条流水线，并用于执行一系列不言自明的脚本。这提高了最终用户对 CI/CD 自动化流程的可视化程度，并提高了 DevOps 团队对流水线的可支持性。 然而，流水线存在一个很大的问题：很难用唯一的流水线支持多个 Jenkinsfile 文件（因此存在多少个项目就存在多少个 Jenkinsfile 文件）。我们需要一个地方存放公共逻辑，这正是 Jenkins 共享库能够实现的。共享库用于存放流水线公共的部分，它定义在 Jenkinsfile 文件中，并允许在其中使用接口简化自动化脚本。 虽然共享库允许你存储公共逻辑并操作 Jenkins，但它们并没有提供一种好的方式去使用这些公共逻辑。所以，MPL 通过允许用户创建易于理解的流程描述来优化流水线和共享库，然后方便其他团队使用。 MPL 致力于创建跨团队协作 DevOps 流程 通过 MPL，我们现在能够跨团队协作和共享 DevOps 实践，轻松地为特定的项目指定特定的流水线，并能在将它们集成到 MPL 库中之前进行调试和测试。每个团队都可以创建一个嵌套库，在其中增加流水线和模块，并在流水线中使用，这样还可以提高流水线的可视化程度。MPL 能够适用于任何包含 Jenkinsfile 文件的项目，还可以根据项目团队的需要灵活地管理它。 https://jenkins-zh.github.io/about/star-plan/ Sun, 03 Mar 2019 00:00:00 +0000 https://jenkins-zh.github.io/about/star-plan/ 统计的基础分数为：GitHub 账号首页上 jenkinsci 、 jenkins-infra 、 jenkins-zh 、 jenkins-x 四个组织的贡献数和。 附加分，统计发表在 Jenkins 公众号上的文章的阅读数，该数字除以100得到的整倍数。例如：某篇文章的阅读数为120，那么得分为1；阅读数为90，则没有得分。 加权，是为了鼓励更多的原创。原创文章的加权数为1.2，例如：某篇原创文章的阅读数为230，那么最终得分为2.4。 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-jenkins-script-console-in-practice/ Wed, 27 Feb 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-jenkins-script-console-in-practice/ 通过脚本命令行批量修改 Jenkins 任务 最近，笔者所在团队的 Jenkins 所在的服务器经常报硬盘空间不足。经查发现很多任务没有设置“丢弃旧的构建”。通知所有的团队检查自己的 Jenkins 任务有没有设置丢弃旧的构建，有些不现实。 一开始想到的是使用 Jenkins 的 API 来实现批量修改所有的 Jenkins 任务。笔者对这个解决方案不满意，经 Google 发现有同学和我遇到了同样的问题。他使用的更“技巧”的方式：在 Jenkins 脚本命令行中，通过执行 Groovy 代码操作 Jenkins 任务。 总的来说，就两步： 进入菜单：系统管理 –> 脚本命令行 在输入框中，粘贴如下代码： import jenkins.model.Jenkins import hudson.model.Job import jenkins.model.BuildDiscarderProperty import hudson.tasks.LogRotator // 遍历所有的任务 Jenkins.instance.allItems(Job).each { job -> if ( job.isBuildable() && job.supportsLogRotator() && job.getProperty(BuildDiscarderProperty) == null) { println " \"${job.fullDisplayName}\" 处理中" job.addProperty(new BuildDiscarderProperty(new LogRotator (2, 10, 2, 10))) println "$job.name 已更新" } } return; /** LogRotator构造参数分别为： daysToKeep: If not -1, history is only kept up to this days. https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-contribution-inspire/ Wed, 27 Feb 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-contribution-inspire/ 自 Jenkins 官方微信公众号开通以来，收到了很多热心、愿意参与开源社区的同学的贡献。这里，包括有 Jenkins 官方博客中的博文翻译，也有 Jenkins 中文站点维护的 Pull Request。我能够看到的是，有些同学从英文技术文章的翻译过程中，对 Jenkins 相关技术的理解更加深入了；而有的则从对 GitHub 不甚了解到逐渐熟悉社区贡献的大致流程；对于深度参与社区贡献的同学，更是能够在“中文本地化”以及 Jenkins 其他的特别兴趣小组（SIG）会议讨论上获得最新的动态。 本着给社区贡献者谋福利的想法，Jenkins 中文社区携手“人民邮电出版社”给大家提供三本技术相关的书籍。从19年3月开始，截止到5月，我们会给予三名贡献者每人一本书。我们会在下次公众号文章中介绍评选规则，欢迎任何一位认可开源、希望参与开源的朋友提出你的建议，不要吝惜你的 PR。获选的同学，按照贡献量可以从下面的列表中依次任选一本： 最后，再次让我们对“人民邮电出版社”给予开源社区的大力支持表示感谢。 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-20-java11-preview-availability/ Wed, 20 Feb 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-20-java11-preview-availability/ NOTE: 这是由 Java 11 支持团队 联合撰写的博客。 在 12 月 18 号（UTC时间下午4点）我们也会在 Jenkins 在线 Meetup 展示对 Java 11 的预览支持。（链接） Jenkins 作为领先的开源自动化服务器之一，目前仍然只支持到 Java 8。在 9 月 25 日 OpenJDK 11 发布了。这是一个长期支持版本，并将持续多年，我们想要在 Jenkins 项目中对这个版本进行全面的支持。在过去的一年中，许多贡献者一直致力于在项目中支持 Java 11（Jenkins JEP-211）。这是一条艰辛的道路，但是现在，代表 Jenkins Platform SIG，我们很高兴的宣布在 Jenkins 每周发布提供 Java 11 预览！ 为什么我们需要 Java 11 的预览？ 这是因为它可以提供给 Jenkins 贡献者和早期使用者一个在明年年初（译者注：此文发布于 2018 年）GA 发布之前尝试这些变化的途径。它也可以帮助我们进行更多的探索性测试，并且有希望在 Jenkins 正式地提供 Java 11 支持之前，解决大部分的问题。 在这篇文章中，我们将会介绍如何在 Java 11 环境下运行 Jenkins，还有如何调查兼容性问题并报告它们。 背景 你可能还记得，在 2018 年 6 月我们举办了一个针对 Java 10+ 支持的在线黑客马拉松。作为黑客马拉松的一部分，我们提供了 Java 11 的实验性支持。这次活动对我们来说非常成功。我们可以在 Java 10 和 Java 11-ea 环境下运行 Jenkins 以及一些主要的功能 —— 包括流水线、JobDSL、Docker/Kubernetes plugin、Configuration as Code、BlueOcean 等。它让我们相信我们可以在 Jenkins 中提供Java 11支持而不会发生破坏性变化。在这场马拉松之后 Oleg Nenashev 创建了 “Java 10+ support in Jenkins”（之后修改为只针对支持 Java 11）。Jenkins Platform SIG 也已成立，以协调 Java 11 的支持工作和其他平台的支持工作（打包，操作系统支持等）。 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-13-outreachy-audit-log-plugin/ Wed, 13 Feb 2019 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-13-outreachy-audit-log-plugin/ 今年是 Jenkins 项目首次参与 Outreachy. Outreachy 是一个类似于 Google Summer of Code (GSoC) 的项目， 实习生有偿地为开源项目工作。 关键的不同之处在于，Outreachy 面向那些在他们国家的技术行业中受到歧视或偏见的小众群体。 当我了解到这个项目后，由于它的包容性与社区建设与我的理念相符就立即自愿作为导师来参与。 我很高兴地说，Jenkins 项目和我的雇主 CloudBees 对此非常支持。 基于我们之前在 GSoC 上指导学生的付出，今年我们已经加入 Outreachy 并指导了两个实习生。 在 Outreachy 的这次活动中，我们的实习生 David Olorundare 和 LathaGunasekar 将与我一起研发 Jenkins 对审计日志的支持。 我很高兴欢迎 David 和 Latha, 并期待他们能在软件工程专业和对开源社区的贡献上都有所收获。 请继续关注后续博客对他们的介绍。 该审计日志支持项目在 Jenkins 和 Apache Log4j 之间形成了一个新的链接，这给予我们的实习生学习 更多有关开源治理和认识新朋友的机会。 作为奖金，该项目旨在为支持高级的业务检测提供便利，例如：在认证事件中检测潜在的入侵尝试。 我们也会编写一个 JEP 来描述由插件提供的审计日志 API,以及其他插件如何定义并记录除 Jenkins 核心以外插件的审计事件。 我期待我们将会一起完成了不起的作品，而且我希望在将来能够帮助更多的 Outreachy 实习生！ https://jenkins-zh.github.io/about/how-to-involve/ Sat, 05 Jan 2019 22:56:04 +0800 https://jenkins-zh.github.io/about/how-to-involve/ 参与开源社区真的不只有 Coding 一条路可选。只要你认同“开源”，有热情，就可以！任何岗位、校大学生、甚至”不懂”技术都能够加入我们。走过路过的朋友们别错过，下面的参与方式总有一种能把你带上开源事业的“不归路”，如果真的没有包含你希望的参与方式，也可以从现在就发起一个 Pull Request 开始： Jenkins 本地化 Jenkins 中文官网 有很多的 翻译任务 需要各路英雄自由领取。无规矩不成方圆，在享受自由的同时，也请牢记如下几点： 认真、负责第一位 翻译任务通常不建议超过两周 翻译规范 翻译包括 Jenkins 官网的本地化，以及 博客 的翻译。翻译完成后，提交 Pull Request 并等待 Review。对于质量较高、或者适合在微信公众号上发布的文章，需要另外提交一个 Pull Request 。 Jenkins 的 简体中文语言插件 也热切地期待你的 Pull Request 。 新手 Bug 如果你之前没有参与过 Jenkins 的贡献或者对如何开始不太情况，可以查看 新手 Bug 。这是一些相对比较简单，容易修改的问题。 分享 你可以在本站或者 Meetup 上分享你在使用 Jenkins 或者相关技术时总结的经验、教训、成果等。 维护本站点 你可以从了解本站的架构开始。小到错别字修正，大到站点风格、架构完善都需要你的参与。 https://jenkins-zh.github.io/about/channels/ Fri, 04 Jan 2019 21:13:30 +0800 https://jenkins-zh.github.io/about/channels/ 为了方便各位 Jenkins 的爱好者、用户以及贡献者之间互相交流，我这里列出来一些途径： 邮件组 即时聊天 在本站留言 邮件组 Jenkins 社区有很多 邮件组 ，感兴趣的童鞋请自行翻阅。本文仅介绍中文相关的邮件组： Jenkins 中文用户邮件组 查看历史 订阅 取消订阅 求助 Jenkins 中文本地化兴趣邮件组 查看历史 订阅 取消订阅 求助 注意：点击上面的订阅或者取消都应该会弹出一个发送邮件的窗口，请不要做任何修改，邮件正文保持空白（不要添加邮件签名等内容）直接发送即可。邮件发送成功后，会收到确认的回复。鉴于邮件组是由 Google 提供的服务，无法科学上网的童鞋是无法查看历史邮件的。 即时聊天 即时聊天是一种很方便的线上交流方式，你有可能及时地收到大家的帮助，但是不要认为其他人有回答问题的义务。你没有能及时地得到帮助，可能是因为大家在忙、消息太多而被忽略、问题描述的不够详细等等。因此，建议大家在提问之前尽可能保证自己已经对问题理解的很清楚，并在提问时尽可能地给出上下文、复现步骤；当没有及时得到回答的话，可以把问题发送到邮件组（发送之前，请在邮件组中搜索其他人是否已经解决过类似问题），相信遇到过类似问题的人也会尽可能帮助你。 Jenkins Gitter 中文聊天室 欢迎你! 留言 本站的留言系统建立在 Github 提供的 Issues 上。欢迎大家在遵守社区行为规范的基础上积极地留言互动。 https://jenkins-zh.github.io/event/readme/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/readme/ 该目录下，保存 Jenkins 社区相关的活动内容。文件格式为 Markdown，包含的头信息（字段）包括如下： type 活动类型，目前只支持 meetup（必需） city 活动举办地（必需） hostDate 活动时间（必需） year 活动所属年份，用于按年度分开展示（必需） poster 活动海报（必需） topic 活动主题 speakers 分享人，数组格式 sponsors 赞助商（公司、社区等），数组格式 abstract 活动简介 agenda 活动日程 time 时间 item 事项 status 活动状态 发起活动 希望发起活动的人或者组织，请按照如上格式写入一个 Markdown 文件中，并打开一个 Pull Request 到该仓库，等待审核。 分享人 对某个活动感兴趣的同学，请在目录 content/speaker 下以 JSON 格式增加自己的个人信息，文件名为 GitHub 账户 ID。然后在您感兴趣的活动中的 speakers 下添加您的 ID。 赞助 如果您所在的企业、出版社、社区等对某个活动感兴趣，打算给 Jenkins 开源社区活动一定的赞助，请参考“分享人”的流程添加自己的信息。 https://jenkins-zh.github.io/event/beijing-2019-11/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/beijing-2019-11/ https://jenkins-zh.github.io/event/hangzhou-2019-05/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/hangzhou-2019-05/ https://jenkins-zh.github.io/event/shanghai-2019-06/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/shanghai-2019-06/ sssdfssfasdfs https://jenkins-zh.github.io/event/shenzhen/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/shenzhen/ https://jenkins-zh.github.io/event/wuhang/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/event/wuhang/ https://jenkins-zh.github.io/sponsor/alauda/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/sponsor/alauda/ https://jenkins-zh.github.io/wechat/articles/readme/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/readme/ 这里存放的是 Jenkins 官方微信公众号文章，文件采用 Markdown 格式，但包含一些必要的描述性字段。文章的校对、审核、排期等都通过 Pull Request 来完成。PR 合并后会发布到 Jenkins 中文社区网站。 目录 文章以发布的排期来存放，层级为：年份/月份。如果月份为个位数的话，要以0开头，例如：01。 文件名 文件名前缀为“年月日”，中间部分需要以英文来描述。例如：2019-01-01-sample.md。 字段 文件中的字段，是为了描述文章相关的必要信息。具体的说明请参考：sample.md。 https://jenkins-zh.github.io/weibo/weibo-operating-charter/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/weibo/weibo-operating-charter/ Jenkins 官方微博运营章程 该文旨在说明 Jenkins 官方微博运营规范。 需要讨论的问题 运营者选取形式 志愿或其他形式 发布的内容 同步微信公众号/同步 Twitter/类似其他机构官方账号与粉丝互动 发布内容的形式（分享/原创长微博） 微博官方提供了分享微博和发布长微博的接口。 发布的时间/频率 微博的自动化 维护 Jenkins weibo plugin，需要进一步测试（较长时间无人维护，可能存在接口变动） 开发新的插件 对评论的回复 https://jenkins-zh.github.io/about/meetups/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/about/meetups/ 我们欢迎每一位愿意一起合作、组织的个人、企业、社区，形式包括但不局限于： 案例、经验分享 工作坊，实际操作演练 活动拍照、录像 茶歇、场地赞助 礼品、奖品赞助 下面是目前收集到的，在国内组织过 Meetup 的城市。 北京 上海 西安 杭州 成都 深圳 广州 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-localization-zh-cn-plugin/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-localization-zh-cn-plugin/ 部分 Jenkins 中文用户可能已经发现，在最近升级 Jenkins 版本，或下载较新的 Jenkins 后，界面上很多部分显示的是英文。对此，我简单介绍一下原因以及如何安装中文插件。 各种语言的本地化资源文件都是集中存放在 Jenkins Core 及其插件中，这对于要做本地化贡献的人来说，需要向很多代码仓库中提交 PR。最明显的一个现象就是，这些仓库不一定都会有熟悉中文的维护者，因此导致 PR 无法真实、及时地进行 Review 以及合并发布。基于以上的考虑，我开发了简体中文插件，并从 Jenkins 2.145 版本中把大部分的中文本地化资源文件迁移到了该插件中。而且，最终会对 Jenkins Core 以及流行的插件中所有的中文本地化资源文件进行迁移。 安装简体中文插件也很简单，只要在 Jenkins 的插件管理界面上，搜索*中文*就能找到该插件。安装并重启后就能看到中文界面。 更多细节请查看 变更记录 。欢迎对中文本地化工作感兴趣的同学加入我们！ https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-30-k8s-jenkins-secet-agent/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-30-k8s-jenkins-secet-agent/ 最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。 如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。 我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。 下面是我在这些年中使用 Jenkins 的各个阶段. 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤 以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes. https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-windows-installers/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-windows-installers/ Jenkins 的 Windows 安装程序已经存在很多年了，它是用户在 Windows 上安装 Jenkins Master 作为服务的一种方式。 从被开发出来至今，它还没有什么新特性，但现在是时候做出改变了。 首先，让我们瞧瞧现版本安装程序的使用经验。 第1步 启动安装程序 这是使用 WiX Toolset Windows 安装程序的默认界面外观，算不上太好看，而且没有太多对安装程序进行说明的品牌信息。 第2步 安装目录 同样，没有太多的品牌信息。 第3步 安装 除了选择安装位置外，安装程序大体上没有提供一些安装 Jenkins 的选项。 问题 现在的安装程序存在一些问题，平台特别兴趣小组会修复这些问题，并为用户提供新的安装体验。 安装程序只支持32位安装。 用户不能选择 Jenkins 作为 Windows 服务启动时的端口以及账户。 安装程序捆绑了32位的 Java Runtime，而没有使用已存在的 JRE。 安装程序不支持 Jenkins for Java 11中的实验性支持。 JENKINS_HOME 目录并不适合现代 Windows。 安装程序中没有品牌。 前进 使用实验性的 Jenkins Windows 安装程序，大部分问题都已解决！ 安装程序将只支持64位系统，这也是如今大多数 Windows 系统的现状，所以能让更多的用户能够使用安装包来安装 Jenkins。 用户能够为服务输入用户信息，同时选择端口以便于 Jenkins 验证端口是否可用。 安装程序不再捆绑 JRE 而是在操作系统中寻找合适的 JRE。如果用户想要使用一个不同的 JRE，可以在安装时指定。 安装程序已经支持 Java 11，包括在 Java 11 预览上面列出的组件。 JENKINS_HOME 目录被放置在启动服务用户的 LocalAppData 目录下，这与现代 Windows 文件系统布局一致。 安装程序已经升级带有品牌了，这让它看起来更酷并能提供一个更好的用户体验。 截图 以下是新安装程序的系列屏幕截图： https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-23-configuring-jenkins-pipeline-with-yaml-file/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-23-configuring-jenkins-pipeline-with-yaml-file/ 几年前，我们的 CTO 写了一篇关于 使用 Jenkins 和 Docker 为 Ruby On Rails 应用提供持续集成服务 的文章。这些年，我们一直使用这个 CI 流水线解决方案，直到我们最近决定做一次升级。为什么呢？ Jenkins 的版本过低，已经很难升级 Wolox 过去几年增长显著，一直面临着如何伸缩的问题 只有极少数人如何修复 Jenkins 服务的问题 配置 Jenkins 任务不是一件简单的任务，使我们的项目启动过程变慢 更改每个作业运行的命令也不是一件简单的任务，并且有权限更改的人并不多。 Wolox 拥有广泛的项目，语言种类繁多，使得这个问题尤为突显。 考虑到这些问题，我们开始深入研究最新版的 Jenkins，看看如何提升我们的 CI 服务。我们需要构建一个新的CI服务，至少要解决以下问题： 支持 Docker 构建。我们的项目依赖的一个或多个 Docker 镜像的执行（应用，数据库，Redis 等） 如有必要，易于配置和复制 易于增加新项目 易于修改构建步骤。工作在项目上的所有人都应该能修改它，如果他们希望执行 npm install 或 yarn install 安装Jenkins和Docker 安装 Jenkins 非常简单，直接从 官方教程 选择一种方式安装。 以下是我们在 AWS 上的安装步骤： sudo rpm — import https://pkg.jenkins.io/debian/jenkins.io.key sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat/jenkins.repo sudo yum install java-1. https://jenkins-zh.github.io/about/about-site/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/about/about-site/ Jenkins 中文社区站点是基于 Hugo 生成的静态文件，托管在 GitHub Page 上。下面列出相关的源码位置： 网站内容 网站主题 微信订阅号 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-webhook-firewalls/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-webhook-firewalls/ 在这篇文章中，我将向大家展示，如何让运行在防火墙内的 Jenkins 依然可以实时地收到 GitHub 的 WebHook。当然，你也可以把这个方法应用到如 BitBucket、 DockerHub 或任何可以推送 WebHook 的其他服务中。但是，下面的步骤仅适用于托管在 GitHub 上的项目。 什么是 WebHook 简单地描述下什么是 WebHook：事件消息（通常是 JSON，也可以是其他的）由服务端以 HTTP(S) 协议发送到监听的客户端。 事件流自左到右，Jenkins 会监听类似 /github-webhook/ 或 /dockerhub-webhook/ 等路径上的 HTTP 请求，唤醒并执行一些任务。 GitHub 或 BitBucket 可能会报告一个新的提交或 PR，DockerHub 报告一个上游的镜像发生了变更。这些事情的共同之处在于，它们会推送给 Jenkins，并期待可以推送成功（例如：可以访问到 Jenkins）。在网络是开放的情况下时，例如 GitHub 企业版 或 Jenkins 在监听公网时，这是可以正常工作的。 内网环境 当有东西挡在中间时，也就是防火墙： （_按照行业标准，所有防火墙都必须能起到屏障的作用。因此，无论如何，请不要在你的组织内搞破坏_） 当你在笔记本电脑上运行 Jenkins 并希望从 GitHub 接收 WebHook 时，这也是一样的。可能是为了测试你的设置，也可能是为了在 Mac 上运行 iOS 版本构建，又或者是部分网络没有暴露在互联网中，这都是合理的。 除非你的笔记本电脑可以让整个互联网访问到（这当然不太可能），或者你的网络配置得恰到好处，否则网络连接将无法流动，此时 WebHook是不可用的。 没关系，我们可以退而求其次，使用轮询变更的方式。只是这样很糟糕。你会用尽 API 配额，还无法实时地获取变更，这真的不是一个好方法。 问题可能也是机会 我们可以解决这个问题，但也可以把这个视为一个机会。有的东西在互联网中不可访问，或者以某些默认的方法锁定是一个特色，不是一个 Bug。你可以很大程度上减少你的攻击面，同时可以进行深度防护： 一个 WebHook 转发服务 输入 link:https://smee.io/[Smee] 这个很容易记住的名字。这是一个由 GitHub 提供的 link:https://github. https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-09-jenkins-evergreen/ Mon, 01 Jan 0001 00:00:00 +0000 https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-09-jenkins-evergreen/ 当我第一次 写 Jenkins Evergreen 相关的文章 ， 后来被称为 “Jenkins Essentials”，我提到的一系列的未来的发展在接下来的几个月里已经变成了 现实 。 今年在旧金山举办的 DevOps World - Jenkins World 会议上，我会介绍 Jenkins Evergreen 背后哲学的更多细节，展示我们已经做了什么，并且讨论这个激进的 Jenkins 发行版的走向。 正如我在第一篇博客以及 JEP-300 中所讨论的 Jenkins Evergreen 的前两大支柱是我们关注的要点. 自动更新的发行版 不出所料, 实现安全、自动地更新Jenkins发行版（包括核心和插件）所需的机制需要很多的工作。在 Baptiste 的演讲中 他将讨论如何使 Evergreen “走起来”，而我会讨论 为何 自动更新的发行版很重要。 持续集成和持续交付变得越来越普遍，并且是现代软件工程的基础 ，在不同的组织当中有两种不同的方式使用 Jenkins 。在一些组织当中，Jenkins 通过 Chef ，Puppet 等自动化工具有条不紊的被管理和部署着。然而在许多其他组织当中， Jenkins 更像是一个 设备 ，与办公室的无线路由器不同。当安装完毕，只要它能继续完成工作，人们就不会太多的关注这个设备。 Jenkins Evergreen 发行版通过确保最新的功能更新，bug 修复以及安全性修复始终能安装到 Jenkins 当中,“让 Jenkins 更像是一个设备”。 除此之外, 我相信 Evergreen 能够向一些我们现在没有完全服务的团队提供良好的服务:这些团体希望能够以 服务 的形式使用 Jenkins 。我们暂时没有考虑提供公有云版本的 Jenkins 。我们意识到了自动接收增量更新，使用户可以在无需考虑更新 Jenkins 的情况下进行持续开发的好处。