🧊2025软件供应链现状报告:开源时代,我们究竟在和谁打交道?

大家好,我是DevOps攻城狮。

最近读了一份挺有意思也挺震撼的报告:JFrog发布的《2025软件供应链现状报告》。这是JFrog连续多年基于其平台数据、CVE趋势分析、安全研究团队研究和1400位开发/安全从业者调查所形成的一份行业报告。

我挑了一些对我们DevOps从业者、尤其是负责CI/CD和软件交付的人来说非常有参考价值的内容,分享如下:

软件供应链,真的变了

报告开头就给出了几个数字,让人警觉:

  • 64% 的企业开发团队使用 7种以上编程语言,44% 使用10种以上;
  • 一个普通组织 每年引入458个新包,也就是每月平均38个;
  • Docker Hub 和 Hugging Face 上的镜像和模型数量仍在指数级增长;
  • npm依然是恶意包的“重灾区”,但 Hugging Face 上的恶意模型增长了6.5倍

Read More

How to Fix Shields.io Badges Not Displaying in Jenkins

Issue

I have set up documentation publishing on Jenkins using the following Groovy code:

publishHTML([
allowMissing: false,
alwaysLinkToLastBuild: false,
keepAll: false,
reportDir: "docs/build/html/",
reportFiles: 'index.html',
reportName: "Documentation",
useWrapperFileDirectly: true
])

However, some badges from Shields.io do not display properly within the published documentation.

Can not display badge on Jenkins

How to fix it

✅ Working Script to Update Jenkins CSP in Script Console

Here’s the correct and minimal Groovy script you should run in Manage Jenkins → Script Console:

System.setProperty(
"hudson.model.DirectoryBrowserSupport.CSP",
"default-src 'self'; img-src * data:;"
)

Read More

提升代码可追溯性:一招把 PR 描述写入 Git commit

背景

最近和同事讨论了一个看似简单但很重要的问题:

我们如何确保 PR 中有价值的信息不会随着时间和工具的更替而丢失?

虽然我们日常使用 Bitbucket 来协作开发,但未来也许会迁移到 GitHub、GitLab 等平台。这些托管平台可能会变,但 Git 本身作为代码历史的记录核心,很可能还会长期存在。

问题也就来了:

PR 页面里描述的变更背景、解决思路和关键讨论,如果只保存在 PR 工具里,就很可能在平台迁移后“消失”。而这些信息,本应是 commit message 的一部分。

我们讨论过的一些方案:

  1. git commit -m 时手动记录问题的解决方式 —— 但容易被忽略或写得不完整。
  2. 模仿 pip 项目使用 NEWS 文件 来记录每次变更 —— 虽然能保留信息,但这种方式更适合用于生成 release note,而不是记录修改的动机或原因。
  3. 强制要求成员把内容写在 Jira ticket 中 —— 工具间割裂,不利于在代码上下文中快速理解历史。

最终我们决定:使用 Bitbucket 的 Commit Message Templates 功能,把 PR 的描述直接写入 Git commit 中。

Read More

如何优雅地控制 Jenkins 构建是否中断?只看这篇

背景介绍

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

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

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

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

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

Read More

How to Change abortPrevious Value in Jenkins?

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 这块,我确实一直在做两件事:

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

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

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

其实并不是。

Read More

asdf-clang-tools:使用 asdf 安装 Clang 工具的新选择

最近,我在 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-queryclang-tidyclang-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

ChatGPT 一开,谁还去“努力”?

分享两个最近的体会

AI 让人感到“虚”

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

当我问他:“你对 AI 有什么感受?”

他说了一个字:虚!

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

Read More

还在用 Wiki/Confluence?你可能在生产垃圾

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

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

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

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

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

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

Read More

还在用 pip 和 venv?那你可真落伍了,赶紧体验 uv!

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

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

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

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

Read More

全程记录|PyCon LT 2025 第三天:AI 能取代你吗?

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

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

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

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

Read More

全程记录|PyCon LT 2025 第二天:被几位女性开发者圈粉了

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

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

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

Read More

全程记录|PyCon LT 2025 第一天:我在异国 Python 大会上的见闻

第一次参加了 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