2025-06-28

DevOps

🧊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倍。

2025-06-23

Jenkins

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.

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:;"
)

2025-06-12

Git

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

背景

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

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

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

问题也就来了：

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

我们讨论过的一些方案：

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

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

2025-06-05

DevOps

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

背景介绍

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

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

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

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

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

2025-06-04

DevOps

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.

2025-06-02

DevOps

CI/CD 不是一次性的项目，而是一个不断演进的系统

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

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

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

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

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

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

其实并不是。

2025-05-29

asdf

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-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 等命令了。