背景介绍

在我们的 Jenkins 流水线中，经常会遇到这样一种情况：当同一个分支或 PR 已有一个构建任务正在运行时，如果此时有新的提交进来，当前构建会被自动中断，转而执行新的构建任务。

这是由于我们需要合理控制资源使用，尤其是对于那些构建时间较长的任务。如果允许同一个分支或 PR 同时触发多个构建，Jenkins Agents 很快就会被大量占用，导致后续任务只能排队等待。

因此，在 Jenkinsfile 中，我们经常会设置这样的选项：

// 禁止并发构建，允许中断前一个任务
disableConcurrentBuilds abortPrevious: true

这段代码你可能在不少 Jenkinsfile 中看到，就算是 Jenkins 团队他们自己的 CI 也是这样设置的。

这样做的好处是显而易见的，但在某些情况时也带来了一个新的问题，比如：

当一个 release 分支正在运行的构建任务，会被新的合并触发的构建中断。尤其是当它即将完成时，却因为新的合并代码触发了新的构建任务，导致前一个任务被中断。

这让 QA 同事很抓狂：一个马上就要交付测试的 Build，结果因为新的合并被中断了，还得重新等待……

于是他们提出了一个需求：

PR 构建可以中断来节省资源没问题，但像 devel 或 release 分支上的构建，如果已经在运行，就不应该被中断。新的合并触发的构建应该排队等待，直到前一个任务完成后再运行。

起初我认为这个设置是全局生效的，没办法按分支进行区分。查了一下 ChatGPT 和 Google，也确实没发现特别简单的方法能做到“某些分支不中断，而是排队”。

后来我想到了一个非常简单的做法：

可以通过一段简单的判断逻辑，在 pipeline 的起始位置判断当前构建是基于哪个分支，然后根据分支类型动态设置 abortPrevious 的值：

def call() {
    def isAboutPrevious = true

    if (env.BRANCH_NAME == 'devel' || env.BRANCH_NAME.startsWith('release/')) {
        isAboutPrevious = false // devel 和 release 分支，不中断
    }

    pipeline {
        options {
            disableConcurrentBuilds abortPrevious: isAboutPrevious
        }
        stages {
            // ... 构建流程
        }
    }
}

最终效果

这段逻辑已经合并到了我们的共享 Jenkins 库中。上线后的表现完全符合预期：

✅ 同一个 devel / release 分支上的构建任务会排队执行，不再中断
✅ 同一个 PR 的构建依然会中断前一个任务，从而节省资源
✅ 无需单独创建 Jenkinsfile，也没有引入复杂逻辑，维护成本极低

改动之前是这样的：

• Job #104：还没跑完就被中断了
• Job #105：同样的命运，又被新合并触发的构建终止了

我们希望达到的效果是：

• Job #106：即使有新的合并，也能继续正常运行
• Job #107：在队列中等待，等 #106 完成后再开始执行

总结一下

如果你也在使用 Jenkins 进行多分支构建，并且对某些特定分支有类似的需求，这个方法值得一试：

简单的一段条件判断，就可以实现按需控制构建是否会被中断。

欢迎大家在留言区交流你们的 Jenkins 构建优化经验！👋

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

Background

In our Jenkins pipeline, we use the following configuration to manage resource consumption, especially for builds that typically take more than 30 minutes to complete:

disableConcurrentBuilds abortPrevious: true

This setting prevents concurrent builds on the same branch or pull request. When a new build is triggered while a previous one is still running, the older build is automatically aborted.

This helps conserve resources and avoids redundant builds when developers push multiple updates shortly after opening a pull request.

The problem

But the problem is:

Sometimes, during merges, an ongoing build gets aborted midway or near completion because a new build was triggered for the same branch.
They requested that if a build is already running, new builds triggered on the same branch should wait in the queue instead of aborting the current build.

Read More

今天这篇文章，起因是我看到前同事发的一条朋友圈。

我感觉他这是在赤裸裸地夸我 ：）
（不好意思，得瑟一下~）

不过说实话，这几年在 CI/CD 这块，我确实一直在做两件事：

• 一边关注行业里最新的实践；
• 一边筛选出适合我们业务的部分落地实施，或者写文章进行分享。

但我发现一个常见的误区是：

很多人觉得 CI/CD 做完了就完了，是一劳永逸的事情。

其实并不是。

Read More

最近，我在 cpp-linter 组织下发布了一个名为 asdf-clang-tools 的全新仓库。这个项目是从 amrox/asdf-clang-tools fork 而来。由于原作者多年没有维护，我对其进行了修复、升级和功能扩展，使其焕然一新。简单来说，asdf-clang-tools 是一个 asdf 插件，用于安装和管理 Clang Tools 相关工具（如 clang-format、clang-tidy、clang-query 和 clang-apply-replacements 等）。

新的安装方式：除了 pip 还有 asdf

在此之前，我曾推出过 clang-tools-pip 工具包，用户可以通过 pip install clang-tools 的方式安装包括 clang-format、clang-tidy、clang-query、clang-apply-replacements 在内的一整套 Clang 可执行工具。

而 asdf-clang-tools 则提供了另一种途径——利用 asdf 版本管理器来安装这些工具。简而言之，这为喜欢用 asdf 管理工具版本的开发者多了一个选择。

这两种方式并不是互斥的：你可以通过 pip 或 asdf 轻松安装和管理 Clang 工具。至于选择哪种方式取决于你的工作流和个人喜好。

什么是 asdf 版本管理器

很多开发者可能还不太熟悉 asdf。asdf 是一个多语言、多工具的版本管理器。

它可以用一个命令行工具管理多种运行时环境的版本，支持插件机制。

举例来说，你可以通过 asdf 来管理 Python、Node.js、Ruby 等语言的版本，也可以管理 Clang 工具（像我介绍的 asdf-clang-tools）。

所有工具的版本信息都记录在一个共享的 .tool-versions 文件中，这样团队可以轻松在不同机器间同步配置。

总之，asdf 的好处就是“一个工具管理所有的依赖”，让项目所需的各类工具版本统一起来，免去在每个工具里使用不同版本管理器的麻烦。

安装与使用示例

使用 asdf-clang-tools 安装 Clang 工具非常简单。假设你已经安装好了 asdf，只需按照官方仓库的说明进行操作：

• 首先 添加插件：以 clang-format 为例，在终端运行：

  asdf plugin add clang-format https://github.com/cpp-linter/asdf-clang-tools.git

  类似地，clang-query、clang-tidy、clang-apply-replacements 等工具也使用相同的仓库地址，只需把插件名改为对应的名称即可。

• 查看可用版本：添加插件后，可以运行 asdf list all clang-format 来列出所有可安装的 clang-format 版本。

• 安装工具：选择一个版本（例如最新的 latest），执行：

  asdf install clang-format latest

  这会下载并安装指定版本的 clang-format 二进制文件。

• 设置全局版本：安装完成后，可以执行：

  asdf set clang-format latest

  这会把版本写入 ~/.tool-versions 文件，实现全局可用。此后，你就可以直接在命令行中使用 clang-format 等命令了。

以上操作完成后，clang-format、clang-tidy 等工具就已集成到 asdf 管理下。更多细节可参考 asdf 官方文档。

欢迎试用并反馈建议

总的来说，asdf-clang-tools 为需要 Clang Tools 的开发者提供了一种新的安装方式。

它与 cpp-linter 组织的其它工具（如 clang-tools-pip）互为补充。

我诚挚欢迎大家尝试 cpp-linter 提供的整个 C/C++ lint 解决方案，选择最适合自己工作流的工具。

同时，如果在使用过程中有任何问题或改进建议，欢迎通过 GitHub Issues、讨论区等渠道提出，一起完善 Cpp Linter 工具链，让 C/C++ 格式化和静态分析工作更加便捷高效！

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

这几年，随着国内就业形势日趋严峻，大家找工作也开始放眼全球。

“我适合出国吗？”

有的人是因为孩子教育，有的人是想逃离内卷、追求生活质量。

但想法和现实之间，常常隔着语言、教育、文化、效率和习惯。

我自己作为一名在欧洲工作的程序员，也时常被问到这类问题：

• “欧洲适合养娃吗？”
• “完全不会英语，能活下去吗？”
• “孩子上学怎么办？英语就够了吗？”
• “工资能攒下钱吗？”

今天，我想站在一个程序员和孩子爸爸的双重视角，再结合自己的观察，总结一下：

什么样的人适合来欧洲，什么样的人可能会感到不适？

Read More

分享两个最近的体会

AI 让人感到“虚”

老同事来欧洲出差，和他聊了很多 —— 从工作到生活，从技术到 AI。

当我问他：“你对 AI 有什么感受？”

他说了一个字：虚！

这让我有些意外。他可是我心中的技术大牛，工作了十几年，积累了很多经验和技能。但如今，他却觉得自己在 AI 面前变得“虚”了。

Read More

不知道你是否也在企业中使用过 Confluence，或者其他类似的 Wiki 工具。刚接触它时，我觉得这玩意儿真不错：功能强大、支持各种排版样式、可以插入图片、视频、图标，还能查看历史版本，使用体验比 Git 轻松太多了。

但慢慢地，我发现了它的一个巨大问题：每个人都可以创建并维护自己的 Wiki 页面。

一开始，这种自由看起来是优势。但时间一长，问题就来了：同一个主题的内容，可能会被不同的人写了多个版本。尤其是在项目或产品从一个团队交接到另一个团队时（在外企这是很常见的操作），新团队成员可能不会在原有文档上继续维护，而是习惯另起炉灶，记录自己的理解。

于是，旧的 Wiki 随着人员流动逐渐失效（原作者可能早已离职），新的 Wiki 内容又不够完善甚至有误。这样一来，知识沉淀不仅没有统一，反而更混乱了。

我始终认为 Wiki 工具本身是好的，但如果缺乏统一的管理机制、没有像 Git 那样的 Pull Request 审批流程，那最终它就容易沦为垃圾信息的生产场。

相比之下，开源社区在这方面反而做得很好。

Read More

如果你已经习惯了 pip install、手动创建虚拟环境、自己管理 requirements.txt，那你可能会对 uv 有些惊喜。

这是一个由 Astral 团队开发、用 Rust 写的 Python 包管理工具，它不仅能替代 pip、venv、pip-tools 的功能，还带来了更快的依赖解析速度，以及一套更现代的项目管理方式。

从 uv init 开始，一键创建项目骨架

我们不从 “怎么装 uv” 讲起，而是从 “怎么用 uv 创建一个项目” 开始。

Read More

今天是我参加 PyCon LT 2025 的第三天：AI and ML Day，主题是 LLM 和 Neural Networks。

全部日程可以在这里查看：PyCon LT 2025

AI 的发展确实很快，我也想借这次大会的机会，听一听关于 AI 的相关讨论。虽然因为下午有工作需要回公司处理，只听了上午的议程，但依然有收获。

主要的收获是：AI 已经成为每个人都不能不学习和应用的技术了。

Read More

今天是我参加 PyCon LT 2025 的第二天：Data Day，主题是 Dataframes、Databases、Orchestration。

全部日程可以在这里查看：PyCon LT 2025

这确实是我不太熟悉的领域，但还是希望来听听，看看能不能有所收获，毕竟门票里也包含了这一天的议程。没想到，今天真正打动我的，竟然是几位技术演讲者中的女性讲者——不仅讲得有料，还有热情、风格、甚至让我顺手关注了几个博客……

Read More

第一次参加了 Python 的大会，没想到是在国外。

虽然这次的规模和演讲嘉宾的知名度不及即将六月份在捷克举办的 PyCon 欧洲大会，但这也是一次不错的体验。

这次 PyCon LT 2025 一共是三天：

• 第一天（4月22日）是 Python Day（Web、Cloud、IoT、Security）
• 第二天（4月23日）是 Data Day（Dataframes、Databases、Orchestration）
• 第三天（4月24日）是 AI and ML Day（LLM、Neural Networks）

全部的日程可以在这里查看：PyCon LT 2025

Read More

上个月回国休假，结束之后从北京转机飞欧洲。因为我们三口之家行李比较多，就订了首都机场附近的酒店，方便第二天出发。趁着在北京停留的这个晚上，就约了几位大学同学小聚一下。

那天是星期二，我大概下午四五点钟到酒店。感谢北京的同学们的热情招待，也挺不好意思的，让他们下班后还大老远跑来机场这边见我一面。

有一个小感慨就是：北京人下班真的挺晚的。

Read More

上周，我创建并维护的开源项目 cpp-linter-action 迎来了一个小小的里程碑：

🌟 GitHub Star 数突破 100！

虽然这个数字不算大，但对我来说是一个小小的里程碑——这是我第一次有项目在 GitHub 上获得超过 100 个 Star，也可以算是对这个项目的认可，给了我持续维护的动力。

我在这个项目的第一次提交是在 2021 年 4 月 26 日，一晃将近 4 年过去了。回头看看这段时间，挺庆幸自己一直没有闲着，也留下了一些对别人有用的东西。

随着项目不断发展，用户也越来越多。根据粗略估算，目前已经有上千个项目在使用这个 Action。

其中不乏一些知名组织和开源项目，比如：

• Microsoft
• Apache
• NASA
• CachyOS
• nextcloud
• Jupyter

最重要的是，这个过程让我收获了很多新的技能和知识，也让我保持了一个「业余习惯」：

手机上除了刷微信、抖音，还有 GitHub。

这个项目也成为了我后续工作的一个起点。我后来创建了 cpp-linter 组织，和其他开发者一起维护并发布 clang-tools 的二进制版本和 Docker 镜像。同时也开发了 cpp-linter-hooks，为用户提供 clang-format 和 clang-tidy 的 pre-commit hook，使用起来更加方便。

不谦虚的说：

如果你的项目是用 C/C++ 开发，如果想使用 clang-format 和 clang-tidy，那么 cpp-linter 会是一个绕不开的选项。

最后，欢迎大家提出意见或建议，也欢迎通过 Issue 或 Discussions 与我交流！

如果你觉得这个项目对你有帮助，也欢迎在公众号「DevOps攻城狮」留言或者去 GitHub 点个 Star，支持下这个项目～

—— 写于 2025-04-15 12:49 AM

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

昨天想必有些人可能已经遇到 GitHub 无法访问的情况了。

网上有人调侃，说是因为美国加征关税，GitHub 的响应码从 200 升级到了 403。

玩笑归玩笑，GitHub 官方后来给出了说明——是配置错误，目前问题已经修复。

刚好前段时间回国了一趟，再次体验到了快递、外卖、出行、支付等方面的便捷和实惠。唯一不太方便的，就是网络。

更准确地说，是那些很多程序员日常离不开的网站和服务，比如 GitHub、Docker Hub、Docker Desktop，还有 ChatGPT。当然，现在我们也有 DeepSeek 这样的替代品了。

就我个人体验来说，GitHub 在国内是可以访问的，但稳定性不太行。经常是刚打开还能用，过一会就彻底加载不出来了。

工作之外，本来每天晚上能用来自由安排的时间本就不多，但却经常不得不花时间来解决网络问题。

虽然也知道可以改 hosts、或者折腾下科学上网，但我的电脑配置起来始终不是很顺利。

这一通折腾下来，感觉真是累了。有时候甚至不想再打开电脑，只想躺着刷会儿手机。

访问 GitHub 的那点坚持，快磨没了。

算了，就当是放个假吧。

转载本站文章请注明作者和出处，请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

在日常的开源项目或团队协作中，我们经常会需要一个易于维护、可自动部署的文档系统。

最近在维护自己的开源项目时，我尝试用 Sphinx 来生成文档，并通过 ReadTheDocs 实现了自动构建和托管，整体体验还不错。

记录一下配置过程，希望能帮到有类似需求的朋友。

为什么选择 Sphinx 和 ReadTheDocs

• Sphinx 是一个用 Python 编写的文档生成工具，最初为 Python 官方文档设计，支持 reStructuredText 和 Markdown（通过插件）。
• ReadTheDocs 是一个文档托管平台，可以自动从你的 Git 仓库拉取代码、构建并发布文档，支持 webhook 自动触发。

这两个工具的组合非常适合持续维护和更新文档，而且社区成熟、资料丰富。

Read More