index.json

[
    {
        "uri": "https://jenkins-zh.github.io/about/code-of-conduct/",
        "title": "行为规范",
        "tags": [],
        "description": "行为规范",
        "content": " 留言 留言之前需要使用 GitHub 账号登陆。大家要注意文明用语，严禁攻击、诋毁、灌水、广告等无关的话。对于违反人，一经发现将会被拉入黑名单。\n提问 欢迎每一位朋友在这里提出与 Jenkins 或相关领域的技术问题，但是，在提问之前建议先在搜索引擎和本站中进行搜索。\n问题至少要包含如下部分：\n 场景以及问题是如何发生的，方便阅读的人复现 软件、环境相关版本信息 日志、截图等（建议使用附件的方式）  出于对回答问题者的尊重，请得到解决方案后及时表示感谢，或者从其他地方得到答案后添加相关链接以及说明。\nGitHub 请您使用同一个 GitHub 账号来与大家交流，不欢迎使用所谓的“小号”。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/about/channels/",
        "title": "交流",
        "tags": [],
        "description": "Jenkins 中文社区交流指南",
        "content": " 为了方便各位 Jenkins 的爱好者、用户以及贡献者之间互相交流，我这里列出来一些途径：\n 邮件组 在本站留言  邮件组 Jenkins 社区有很多 邮件组 ，感兴趣的童鞋请自行翻阅。本文仅介绍中文相关的邮件组：\n           Jenkins 中文用户邮件组  查看历史  订阅 取消订阅   Jenkins 中文本地化兴趣邮件组  查看历史  订阅 取消订阅     注意：点击上面的订阅或者取消都应该会弹出一个发送邮件的窗口，请不要做任何修改直接发送即可。邮件发送成功后，会收到确认的回复。鉴于邮件组是由 Google 提供的服务，无法科学上网的童鞋是无法查看历史邮件的。\n  留言 本站的留言系统建立在 Github 提供的 Issues 上。欢迎大家在遵守社区行为规范的基础上积极地留言互动。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/about/",
        "title": "",
        "tags": [],
        "description": "",
        "content": "我们是由 Jenkins 社区在国内的爱好者、贡献者组成。\n请准守我们的行为规范，文明留言。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-19-jenkins-survey/",
        "title": "2018年 Jenkins 国内使用情况调查问卷",
        "tags": ["survey"],
        "description": "共建开放、包容、活跃的 Jenkins 社区",
        "content": "近年来，在数字化转型的压力之下，以 DevOps 和微服务为代表的云原生技术，作为企业数字化转型的重要支撑，活跃于开源技术的舞台。 而 DevOps 作为一种理念，落地交付必然离不开 CI/CD 等工具的支持。 Jenkins 在此方面的重要作用，相信大家也是有目共睹。Jenkins 之所以深受国内用户的喜爱，不仅因为它开源免费、功能强大、插件众多，其背后社区的开放、包容和活跃，更是其生命力之所在！\n在新的一年里， Jenkins 社区希望能够更好地推广和传播这项技术，使越来越多的 Jenkins 中文用户能在实际工作中体会它的魅力。正因如此，我们发起了 “2018年 Jenkins 国内使用情况调查问卷”，希望通过这份问卷的互动，我们能够更加清晰 Jenkins 社区2019年的发展方向。\n请扫一扫下面的二维码，或者在微信中长按识别，完成下面的问卷。只需要占用您大概1～2分钟的时间。 问卷有效时间，从 2018年12月19日 到 2019年1月9日 截止。\n另外，还有两则好消息与大家分享。\n第一则好消息是 Jenkins 中文站点已经正式上线，大家可以在上面找到入门教程、使用案例以及优秀的技术博客，我们会不断完善相关文档和教程。当然，无论是贡献文档、代码，还是其他任何形式的贡献，非常欢迎大家参与其中。从来没有参与过开源项目的朋友也不用担心，可以通过微信公众号留言给我们，志同道合的小伙伴们会主动与你联系，助你一同踏入精彩的开源世界。\n另一则好消息是我们将通过此官方微信公众号，陆续推出 Jenkins 相关系列视频，由浅入深地为使用者们介绍 Jenkins 相关知识及使用经验。对于“如何构建特定语言的项目”、“如何在 Kubernetes 集群中更好地利用 Jenkins ”以及“如何排查问题”等大家感兴趣的热门话题，都可以从这些视频中得到经验分享。\n最后，欢迎订阅 Jenkins 中文邮件组与我们进行交流和互动。衷心希望能够通过更多小伙伴的加入，不断完善开源社区氛围，深度技术互动，协力共建一个更加开放、更加包容、更加活跃的 Jenkins 社区！\n有内容、有态度的 Jenkins 社区，期待有你同行！\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/categories/",
        "title": "Categories",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/cloud-native/",
        "title": "Cloud Native",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/community/",
        "title": "Community",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/configuration-as-code/",
        "title": "Configuration as Code",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/core/",
        "title": "Core",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-5-custom-war-packager/",
        "title": "Custom WAR Packager",
        "tags": ["tools", "docker", "jenkins-x", "cloud-native"],
        "description": "打造你自己的 Jenkins！了解自定义 WAR/Docker Packager",
        "content": "我打算给 Jenkins 管理员和开发者介绍一个新的工具 Custom WAR Packager。该工具可以打包 Jenkins 的自定义 WAR 发行版、 Docker 镜像和 Jenkinsfile Runner 包。 它可以打包 Jenkins、插件以及配置为开箱即用的发行版。 Custom WAR Packager 是我们在博客 A Cloud Native Jenkins(/blog/2018/09/12/speaker-blog-a-cloud-native-jenkins/) 中介绍过的无状态 Jenkins master 工具链的一部分。这个工具链已经在 Jenkins X 中被使用，用于构建 serverless 镜像(https://github.com/jenkins-x/jenkins-x-serverless)。\n在这篇文章中，我将会介绍几种 Custom WAR Packager 常见的使用场景。\n== 历史\n正如 Jenkins 本身一样，Custom WAR Packager 开始于一个小的开发工具。在 Jenkins 内运行集成测试很长时间以来都是一个难题。 对此，我们有三个主要的框架： Jenkins Test Harness, Acceptance Test Harness, 和 Plugin Compatibility Tester. 这些框架都需要一个 Jenkins WAR 文件来运行测试。但是假如你想在类似 AWS 一样的自定义环境中进行 Jenkins 测试呢？ 或者，你希望基于 Pluggable Storage 的环境也可以复用 Jenkins 流水线测试，来确保没有回归缺陷？\n这并不是一个无意义的问题。Jenkins 项目中有重大的活动正在进行：云原生 Jenkins、Jenkins Evergreen 以及 Jenkins X。 这些都需要很多集成测试来保障持续部署流程。为了复用已有的框架，我们需要打包一个自带配置的 WAR 文件，使得可以在已有的框架中运行集成测试。 这正是 Custom WAR Packager 于 2018年4月 创建的原因。到 2018年9月，它相继支持了 Docker 镜像和 Jenkinsfile Runner， 后者由 Kohsuke Kawaguchi 创建并由 Nicolas de Loof 完善。\n== 包含的内容？\nCustom WAR Packager 是一个工具，可以作为命令行、Maven 插件或者 Docker 来用。 它从用户那获取配置和包。所有内容都由一个 YAML 配置文件管理：\nimage::/images/post-images/2018-10-16-cwp/cwp_flow.png[Custom WAR Packager 构建流程]\n它支持多种输入类型。插件列表可以来自 YAML,pom.xml 或一个 BOM(jep:309[] 提出的 Bill of Materials) 文件。 Custom WAR Packager 不仅支持发布版本，还可以构建部署到 增量仓库 (Jenkins 核心及插件的 CD 流程 - jep:305[])， 甚至直接从 Git 或指定目录中构建。它允许构建的包来自任何源，而无需等待官方的发版。 构建过程也非常快，因为，插件已经通过 Commit ID 缓存到了本地的 Maven 仓库中。\nCustom WAR Packager 还支持下面的配置选项：\n** Jenkins 配置即代码 的 YAMl 文件 ** Groovy Hooks （例如：预配置的 init hooks） ** 系统属性\n== WAR 打包\n每当这个库构建时会打包出来一个 WAR 文件。 通常，Custom WAR Packager 会根据下面对 Jenkins 核心和 JCasC 的配置把所有内容打包的一个 WAR 文件中。\n样例配置：\nbundle: groupId: \u0026quot;io.jenkins.tools.war-packager.demo\u0026quot; artifactId: \u0026quot;blogpost-demo\u0026quot; vendor: \u0026quot;Jenkins project\u0026quot; description: \u0026quot;Just a demo for the blogpost\u0026quot; war: groupId: \u0026quot;org.jenkins-ci.main\u0026quot; artifactId: \u0026quot;jenkins-war\u0026quot; source: version: 2.138.2 plugins: - groupId: \u0026quot;io.jenkins\u0026quot; artifactId: \u0026quot;configuration-as-code\u0026quot; source: # Common release version: 1.0-rc2 - groupId: \u0026quot;io.jenkins\u0026quot; artifactId: \u0026quot;artifact-manager-s3\u0026quot; source: # Incrementals version: 1.2-rc259.c9d60bf2f88c - groupId: \u0026quot;org.jenkins-ci.plugins.workflow\u0026quot; artifactId: \u0026quot;workflow-job\u0026quot; source: # Git git: https://github.com/jglick/workflow-job-plugin.git commit: 18d78f305a4526af9cdf3a7b68eb9caf97c7cfbc # etc. systemProperties: jenkins.model.Jenkins.slaveAgentPort: \u0026quot;9000\u0026quot; jenkins.model.Jenkins.slaveAgentPortEnforce: \u0026quot;true\u0026quot; groovyHooks: - type: \u0026quot;init\u0026quot; id: \u0026quot;initScripts\u0026quot; source: dir: src/main/groovy casc: - id: \u0026quot;jcasc\u0026quot; source: dir: casc.yml  == Docker 打包\n为了打包 Docker，Custom WAR Packager 使用官方的 Docker 镜像 jenkins/jenkins 或同样格式的其他镜像。构建中，WAR 文件会被该工具所替换。这也就意味着镜像的 所有 特色在该自定义构建中都可用： plugins.txt, Java 选项, Groovy hooks 等等。\n## ... ## WAR configuration from above ## ... buildSettings: docker: build: true # Base image base: \u0026quot;jenkins/jenkins:2.138.2\u0026quot; # Tag to set for the produced image tag: \u0026quot;jenkins/custom-war-packager-casc-demo\u0026quot;  例如：示例 展示了打包带有将构建日志存储到 Elasticsearch 的 Docker 镜像。 尽管这些已经作为了 jep:207[] 和 jep:210[] 的一部分，你还是可以查看这个示例，了解该 Docker 镜像是如何配置、连接到 Elasicsearch、 然后启动外部的日志存储，而不需要改变日志的界面。一个 Docker Compose 文件对于运行整个集群是必要的。\n== Jenkinsfile Runner 打包\n这可能是 Jenkinsfile Runner 最有意思的模式。 三月份，在开发者列表中 宣布了 一个新的项目 Jenkinsfile Runner。 大体的思路是，支持在单一 master 上只运行一次并打印输出到控制台的 Jenkins 流水线。 Jenkinsfile Runner 作为命令或一个 Docker 镜像来运行。 虽然只推荐 Docker 的形式，但是 Custom WAR Packager 都能够生成。 有了 Jenkinsfile Runner 你可以像下面的方式来运行流水线：\ndocker run --rm -v $PWD/Jenkinsfile:/workspace/Jenkinsfile acmeorg/jenkinsfile-runner  当我们开始在云原生特别兴趣小组（Cloud Native SIG）中开始研究无状态（也就是“一次”）时， 有一个想法就是使用 Custom WAR Packager 和其他已有的工具（Jenkinsfile Runner, Jenkins Configuration as Code 等）来实现。 也许只是替换 Jenkinsfile Runner 中的 Jenkins 核心的 JAR 以及插件，但这还不够。 为了高效，Jenkinsfile Runner 镜像应该启动的 *很快*。在这个实现中，我们使用了 Jenkins 和 Jenkinsfile Runner 一些实验性的选项， 包括：类加载预缓存、插件解压等等。有了这些后，Jenkins 使用 configuration-as-code 和几十个插件可以在几秒钟内启动。\n那么，如何构建自定义 Jenkinsfile Runner 镜像呢？尽管现在还没有发布，我们继续实现上面提到的内容。\n##... ## WAR Configuration from above ##... buildSettings: jenkinsfileRunner: source: groupId: \u0026quot;io.jenkins\u0026quot; artifactId: \u0026quot;jenkinsfile-runner\u0026quot; build: noCache: true source: git: https://github.com/jenkinsci/jenkinsfile-runner.git commit: 8ff9b1e9a097e629c5fbffca9a3d69750097ecc4 docker: base: \u0026quot;jenkins/jenkins:2.138.2\u0026quot; tag: \u0026quot;onenashev/cwp-jenkinsfile-runner-demo\u0026quot; build: true  你可以从 这里 找到用 Custom WAR Packager 打包 Jenkinsfile Runner 的例子。\n== 更多\n还有很多其他的特色没有在本文中提到。例如：它还可以修改 Maven 构建配置或增加、替换 Jenkins 核心中的库（例如：Remoting）。 请查看 Custom WAR Packager 文档 获取更多信息。这个库中还有很多示例。\n如果你有兴趣对这个库做贡献，请创建 PR 并抄送 @oleg-nenashev 和 Raul Arabaolaza，第二位维护者正在研究 Jenkins 自动化测试流程。\n== 下一步？\n还有很多值得改进的地方可以让这个工具更加高效：\n 增加对插件依赖传递的检查以便在构建过程中发现冲突 允许在 YAML 配置文件中设置各种系统属性和 Java 选项 改进 Jenkinsfile Runner 的性能 集成到 Jenkins 集成测试流程中，(查看 Jenkins 流水线库中的 essentialsTest())  还有很多其他的任务需要在 Custom WAR Packager 中实现，但是，现在它已经能够让 Jenkins 用户构建他们自己的发行版。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/docker/",
        "title": "Docker",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-26-official-docker-image/",
        "title": "Docker Hub 上的官方 Jenkins 镜像",
        "tags": ["docker"],
        "description": "正确地使用 Jenkins 镜像",
        "content": " 目前，在 Docker Hub 上有三个不同的仓库正（或曾经）被当作“官方” Jenkins 镜像。 本文是为了申明哪个是当前的官方镜像(截至2018年12月).\n官方的 docker pull jenkins/jenkins\n例如：https://hub.docker.com/r/jenkins/jenkins/ 是正确的仓库。\n在我的博客 对于使用 Jenkins 官方 Docker 镜像推荐的方法 上也有一些记录。\n废弃的 jenkins 已经废弃了很久。 我们停止使用和更新该镜像的简短原因是，我们每次发版时都需要人工参与。 jenkinsci/jenkins 同样已经废弃了很久，但为了过渡，我们会同时更新 jenkins/jenkins（正确的那个） 和 jenkinsci/jenkins。 2018年12月初，我们停止更新 jenkinsci/jenkins（如果您感兴趣的话，查看 INFRA-1934 可以获取更多详情）。\n感谢您的阅读！\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/about/meetups/",
        "title": "Jenkins Area Meetup",
        "tags": [],
        "description": "Jenkins 中国本地活动",
        "content": "我们欢迎每一位愿意一起合作、组织的个人、企业、社区，形式包括但不局限于：\n 案例、经验分享 工作坊，实际操作演练 活动拍照、录像 茶歇、场地赞助 礼品、奖品赞助  下面是目前收集到的，在国内组织过 Meetup 的城市。\n  北京   上海   西安   杭州   成都   深圳   广州   "
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-12-gasc/",
        "title": "Jenkins Configuration-as-Code: 看，我都不用手动配置",
        "tags": ["configuration-as-code", "jenkinsworld", "jenkinsworld2018"],
        "description": "JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件",
        "content": " NOTE: 这篇文章是 Configuration-as-Code 系列的第一部分。\nJenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥有一个活跃的社区来维护几乎所有工具和用例的插件。但是灵活也是要付出代价的：除了 Jenkins 核心之外，许多插件需要一些系统级别的设置才能正常工作。\n在某些情况下，“Jenkins 管理员”是一个全职职位。 Jenkins 管理员在负责维护基础设施的同时，还要为一个巨大的 Jenkins master 提供数百个已安装的插件和数千个托管作业。 维护最新的插件版本是一项挑战，故障转移（failover）也会是一场噩梦。\n这就像几年前系统管理员必须要为每个服务管理特定的机器一样。 在 2018 年，通过使用基础架构自动化工具和虚拟化，一切都可以作为代码进行管理。 需要一个新的应用服务器作为你的应用的暂存环境吗？那你只需要部署一个 Docker 容器。 基础设施缺少资源吗？那就在你喜欢的云服务上分配更多资源来使用 Terraform。\n在这种情况下，Jenkins 管理员的角色怎么样？他们是否还要花费数小时来点击网页表单上的复选框？也许他们已经采用了一些自动化、依赖于 Groovy 脚本或一些自己写的 XML 模板。\n今年早些时候我们发布了第一个 alpha 版本的 “Jenkins Configuration-as-Code” （JCasC），它是一种基于 YAML 配置文件和自动模型发现的 Jenkins 配置管理新方法。\u0026rdquo;JCasC\u0026rdquo; 已经升级为顶级 Jenkins 项目。 同时，对应的 Jenkins 增强提案已经被接受。\nJCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。 与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。 这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。\n下面是一个例子：\n[source, yaml] jenkins: systemMessage: \u0026ldquo;Jenkins managed by Configuration as Code\u0026rdquo;\nsecurityRealm: ldap: configurations: - server: ldap.acme.com rootDN: dc=acme,dc=fr managerPasswordSecret: ${LDAP_PASSWORD} cache: size: 100 ttl: 10 userIdStrategy: CaseInsensitive\ngroupIdStrategy: CaseSensitive 如你所见，不需要很长的解释你就可以理解这个 YAML 文件如何配置你的 Jenkins master。\n== 优点\nJCasC 最直接的好处就是可重复性。 管理员现在可以使用完全相同的配置通过一个简单的设置来引导新的 Jenkins master。 这允许他们创建一个测试实例并检查升级插件在沙盒环境中的影响。 这也使他们对故障转移和灾难恢复方案更有信心。\n当管理员开始在源代码管理中管理 Jenkins 的 YAML 配置文件时，他们也会感受到类似使用 Terraform 一样的好处。 这样做可以让他们对 Jenkins master 配置进行审核，使其具有可逆性。 他们可以建立一个合理的配置改变运行 Jenkins 实例的工作流，并确保在实际应用任何修改到他们的 Jenkins master 之前配置是健康的。\n最后也是最重要的是，由于能够快速设置 Jenkins master 并且能用一组共享的 YAML 配置文件控制它们，管理员现在可以给每个团队提供一个 Jenkins 实例，并且在安装插件有更高的灵活性。 只要他们还在使用 Jenkinsfiles 管理构建定义（build definition），master 就会或多或少地成为你们团队的短期的基础架构。\n使用 Configuration-as-Code，我们可以不再像对待宠物那样对待我们的 Jenkins master，而像对待牛那样管理它们，你也可以毫不费力地替换它们。 欢迎来到 “as-code” 的世界。\n.他们仍然很可爱，对吧? Cattle not pets\nOk, 那么之后呢? 你可以在项目中阅读有关 Jenkins Configuration-as-Code 插件的更多信息。 与社区和贡献者们交流，加入我们的 gitter 频道， 或者来我们的 Jenkins World 一起讨论 JCasC 项目及其未来！\n另外，不要错过 Configuration-as-Code 系列的下一篇文章，我们将会了解 JCasC 如何处理密码及其他凭据等敏感数据。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/jenkins-x/",
        "title": "Jenkins X",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/",
        "title": "Jenkins 中文社区",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-11-14-first-voice/",
        "title": "Jenkins 微信订阅号",
        "tags": [],
        "description": "来自 Jenkins 官方的消息",
        "content": "Jenkins 作为 CI/CD 领域里非常有实力和生命力的平台，不但在国外有很多用户，在国内也有很多的拥趸者。大家拥抱 Jenkins，不仅仅因为它是新的方向，更因为这背后有着一个非常开放、活跃的开源社区。\n为了使更多的 Jenkins 中文用户，能够及时、准确地获得来自官方的最新动态，经过社区贡献者的讨论，大家一致认为，开通 Jenkins 微信订阅号是非常必要也非常有意义的一件事情。同时，Jenkins 的创始人 Kohsuke Kawaguchi 先生对这个想法非常认同，他亲自签名并授权，对我们创建 Jenkins 微信订阅号提供了巨大的支持和鼓励。\n于是，Jenkins 微信订阅号便在今天，正式与您见面了。\n随着 Jenkins 订阅号的开通，我们将有更加直接的平台来与各位分享社区目前在做的一些事情。在这之前，我们早已着手进行 Jenkins 中文本地化的相关工作。目前社区贡献者主要在做的事情包括：创办并维护 Jenkins 以及 Jenkins X 的中文官网、Jenkins Core 以及插件的本地化等。\n如果您愿意和其他 Jenkins 用户进行线下面对面的交流和分享，Jenkins Area Meetups（后文简称“JAM”） 将会是一个不错的选择。目前，在社区贡献者和技术爱好者的共同努力下，我们已经在北京、深圳、西安等地成功举办过多次 JAM 活动。在 JAM 上，您除了可以体验到很多有关 Jenkins 的实际应用、最新特性之外，还可以结识社区里的朋友并进行深度互动。\nJenkins 社区贡献者们秉承传播 Jenkins 技术、加强互动交流、推动 Jenkins 中文本地化的理念，将在今后定期举办多种多样的线上线下活动。我们尊重任何形式、任何规模的贡献，并热忱地欢迎新贡献者的加⼊，也欢迎您联系我们来分享您的心得、体会，或者共同举办一次 JAM 活动。Jenkins 官网对如何参与有更加详细的说明，有任何问题，欢迎大家留言给我们。\n我们衷心希望，随着 Jenkins 订阅号的开通，能够与更多的小伙伴们一同在线上完善开源社区氛围、线下深度互动，努力构建一个有内容、有态度的优质技术社区。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-26-security-updates/",
        "title": "Jenkins 的重要安全更新",
        "tags": ["core", "security"],
        "description": "重要安全更新",
        "content": " 我们刚刚发布了版本 2.154 和 LTS 2.150.1 的 Jenkins 安全更新，修复了多个安全漏洞。 由于 2.150.1 是新的 LTS 中的第一个版本，而且，我们还发布了上一个 LTS 2.138.4 版本的安全更新。 这使得管理员们可以安装今天的安全修复，而不必立即升级到新的 LTS 版本。\n查看 link:/security/advisory/2018-12-05[安全报告]，了解有哪些被修复。 查看我们的 link:/doc/upgrade-guide/2.138/#upgrading-to-jenkins-lts-2-138-4[LTS 2.138.4 升级指导]，了解影响范围。\n当前修复中有关之前发布变更的部分 在八月和十月份的 Jenkins 核心安全更新中，包括一项改进，可以通过设置多个系统属性来禁用。 那些变更是 SECURITY-595 修复的重要部分，因此，我们强烈建议禁用。而且，之前发布的文档已更新。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/jenkinsworld/",
        "title": "Jenkinsworld",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/jenkinsworld2018/",
        "title": "Jenkinsworld2018",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/performance/",
        "title": "Performance",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/remoting/",
        "title": "Remoting",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/scalability/",
        "title": "Scalability",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/security/",
        "title": "Security",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/survey/",
        "title": "Survey",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/",
        "title": "Tags",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/tags/tools/",
        "title": "Tools",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/",
        "title": "Wechats",
        "tags": [],
        "description": "",
        "content": ""
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-19-scaling-network-connections/",
        "title": "从 Jenkins Master 扩展网络连接",
        "tags": ["jenkinsworld", "jenkinsworld2018", "cloud-native", "performance", "scalability", "remoting"],
        "description": "从 Jenkins Master 扩展网络连接",
        "content": "Oleg Nenashev 和我今年将在旧金山的 DevOps World | Jenkins World 上，做从 Jenkins Master 扩展网络连接 的演讲。 多年来，我们一直致力于分析、优化和加强 Remoting channel， 才有了现如今 master 能够协调 agent 的活动，并且接收构建的结果。 尽管许多技术可以改进服务，比如优化代理启动器，但是想要有质的改变，只有从根本上改变传播的内容和方式。\n3月，JENKINS-27035 引入了一个框架，用于检查 Remoting channel 在高级别上的通信。 以前，开发人员只能使用一般的低级工具，例如 Wireshark， 它不能精确的识别 Jenkins 负责通信的代码片段。\n在过去的几个月里，Cloud Native SIG 在解决根本原因方面取得了进展。 Artifact Manager on S3 plugin 已经发布并与 Jenkins Evergreen 整合， 支持在 agent 和 Amazon 服务器之间，进行大制品的上传和下载， 源生插件允许由 agent 生成的所有构建的日志内容（例如在 steps 的 sh 中） 直接定向流到外部存储服务，如 AWS CloudWatch Logs。 与此同时也开始上传 junit 格式的测试结果，这些测试结果有时会变的很大，将直接从 agent 到存储数据库。 所有这些努力都可以减轻 Jenkins Master 和本地网络的负载，而不需要开发人员修改他们的 pipeline 脚本。\n其他方法也在酝酿之中。 虽然“一次性”的 agent 在新的 vm 或容器中运行，可以极大地提高可重复性， 但是每一次构建都需要传输兆字节的 Java 代码，所以 Jenkins 的特征是需要对它们建立预缓存。 使用 Apache Kafka 的工作正在进行中，以使得通道在网络故障时更加健壮。 最引人注目的是，这个提议 Cloud Native Jenkins MVP 将消除单个 Jenkins Master 服务处理数百个构建的瓶颈。\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/about/about-site/",
        "title": "关于本站",
        "tags": [],
        "description": "本站的架构",
        "content": "Jenkins 中文社区站点是基于 Hugo 生成的静态文件，托管在 GitHub Page 上。下面列出相关的源码位置：\n 网站内容 网站主题 微信订阅号  "
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-12-25-year-in-review/",
        "title": "回顾 2018: 革新的一年",
        "tags": ["core", "community"],
        "description": "Jenkins 创始人 KK 先生的年终总结",
        "content": "临近年终，是一个思考总结、展望全局的好时机。那就让我们暂时从日常繁复的工作中停下脚步，一起来盘点 Jenkins 在 2018 这一年的得失与喜乐。\n在整个行业中，对进一步自动化的不懈追求仍在继续。我们正以前所未有的速度编写软件，与此同时，对于软件的需求似乎越来越高，我觉得越来越多的企业和高管都敏锐地意识到软件和开发者已登基为王。在底层的角度，我遇到的每个团队都认为软件交付自动化是他们的“软件工厂”的关键部分，对这些团队而言，创建、管理具有不可思议的灵活性和可视性的自动化十分重要。\n自诞生14年以来，Jenkins 将继续在实现这一目标上发挥重要作用，总之，增长的步伐似乎正在加速。在这个发展飞快的行业里，成为这一成就的一份子着实让我感到自豪。\n把 Jenkins 打造为每个人都会使用的工具，这具有很大的责任感。所以在 Jenkins 社区，我们一直都十分努力。事实上，在各个领域和层面上来说，*2018年是整个项目历史上最具有创新性的一年*。\n 随着不断发展壮大，我们亟需探索出能使更多人更好地参与其中的方法。JEPs 和 SIGs 便应运而生。2018年，我们看到了这些形式得到了巨大的吸引力。经过一年的运营，我认为我们已经学到了很多东西，希望我们会在此基础上继续改进。 这些新的形式带来了新的协作方式。例如：中文本地化 SIG运营的 微信公众号和本地化网站。平台 SIG 在 Java 11 support 中也给予了不少帮助。 我也很高兴看到新一批领导者。由于害怕遗漏一些人，所以我不打算在此一一列出，我们在今年秋天祝贺他们中的许多人作为 Jenkins 大使（请在明年提名更多人!）。那些领导关键工作的人往往是那些不熟悉这些角色的人。 一些领导者也努力发掘新的贡献者。我们正在有意识地思考，我们哪一部分的潜在贡献者没有被发掘出来，为什么没有被发掘出来。这也是任一个企业都在做的事情。同时我们也是 Google Summer of Code 和 Outreachy 参与者。 今年我们的安全流程和修复速度再次大幅提升，反映出用户对我们的信任也随之增强。例如，我们今年推出了遥测系统，通知我们更快地开发出更好的修复方案。  现在，社区改进的最重要的地方是我们为您使用的软件带来的影响。在这一方面，我认为我们在2018年做得不错，产生了我所谓的“五个超级武器”\n Jenkins X 可能是今年最明显的创新，使得在 Kubernetes 上创建现代云应用程序变得更加容易。这也标志着 Jenkins 社区及其使命的重大扩展。 Jenkins Configuration as Code 在今年达到了一重要的里程碑 \u0026ldquo;1.0\u0026rdquo; ，并且他继续获得更大的动力。 \u0026ldquo;Cloud Native Jenkins\u0026rdquo; 是我为新努力作的术语，把 Jenkins 转换为 Kubernetes 上大规模运行的通用 CI/CD 引擎。这里还有许多东西需要定义，但你已经可以看到如 Serverless Jenkins 这样的好东西了。 Evergreen 是另一个需要推出的新项目，它有着雄心勃勃的主题——大量地简化了 Jenkins 的使用和操作。 流水线方面的努力形成了一个新的 SIG，我期待它在2019年带来的新影响。  Jenkins 社区能够将用户可见的改变与社区的改进结合在一起，这不仅是不算秘密的秘密，也是社区不断发展的能力。 展望2019年，毫无疑问，随着我们不断地学习和实践，上述提到的事情将不断地发展、变化、融合和分裂。\n所以，请在 Twitter 上关注 @jenkinsci 和 @jenkinsxio，了解我们将如何发展的最新动态，加入我们的社区来共同构建震撼世界的软件。多少开源项目敢说出这种话呢？\n"
    },
    {
        "uri": "https://jenkins-zh.github.io/wechat/articles/2018-11-21-validate-jenkinsfile/",
        "title": "在 VS Code 中校验 Jenkinsfile",
        "tags": [],
        "description": "VS Code 中的 Jenkinsfile 插件",
        "content": "在日常工作中，我经常需要创建或修改很多 Jenkinsfile，有时还会发生错误。这是一个非常繁琐的流程——修改 Jenkinsfile，提交、推送，然后等 Jenkins 提醒你少加了一个括号。\nCommand-line Pipeline Linter(https://jenkins.io/doc/book/pipeline/development/) 可以有效地减少编写 Jenkinsfile 所需要的调试时间，但是它也有一些不方便的地方。你需要使用像 curl 或 ssh 的工具来连接你的 Jenkins，还需要正确地记住验证 Jenkinsfile 的命令。尽管如此，对我来说，这个方案还是不尽如人意。\n鉴于每天都会使用 VS Code，于是我开始着手为此研发插件，使得校验 Jenkinsfile 变得更加友好。\nJenkins Pipeline Linter Connector 的作用就是，把当前打开的文件推送到你的 Jenkins，然后在 VS Code 中显示校验结果。\n你可以在 VS Code 插件浏览器中或通过下面的地址找到该插件 https://marketplace.visualstudio.com/items?itemName=janjoerke.jenkins-pipeline-linter-connector 。\n该插件会在 VS Code 中添加四个配置选项，你必须要使用这些选项来配置用于验证的 Jenkins。\n jenkins.pipeline.linter.connector.url 是 Jenkins 期望的 POST 请求地址，包含你要校验的 Jenkinsfile 文件。通常为 *http:///pipeline-model-converter/validate*。 jenkins.pipeline.linter.connector.user 允许指定你的 Jenkins 用户名。 jenkins.pipeline.linter.connector.pass 允许指定你的 Jenkins 密码。 jenkins.pipeline.linter.connector.crumbUrl 当你的 Jenkins 启用了 CRSF 时必须指定。通常为 *http:///crumbIssuer/api/xml?xpath=concat(//crumbRequestField,%22:%22,//crumb)*。 ​  "
    }]