<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>CI/CD on 知识铺的博客</title>
    <link>https://index.zshipu.com/ai001/tags/CI/CD/</link>
    <description>Recent content in CI/CD on 知识铺的博客</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Sat, 05 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://index.zshipu.com/ai001/tags/CI/CD/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>GitHub 自托管 Runner 将在 2026 年彻底停用旧版本</title>
      <link>https://index.zshipu.com/ai001/post/20260905/GitHub-%E8%87%AA%E6%89%98%E7%AE%A1-Runner-%E5%B0%86%E5%9C%A8-2026-%E5%B9%B4%E5%BD%BB%E5%BA%95%E5%81%9C%E7%94%A8%E6%97%A7%E7%89%88%E6%9C%AC/</link>
      <pubDate>Sat, 05 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260905/GitHub-%E8%87%AA%E6%89%98%E7%AE%A1-Runner-%E5%B0%86%E5%9C%A8-2026-%E5%B9%B4%E5%BD%BB%E5%BA%95%E5%81%9C%E7%94%A8%E6%97%A7%E7%89%88%E6%9C%AC/</guid>
      <description>GitHub 自托管 Runner 将在 2026 年彻底停用旧版本 GitHub 明确给出最终截止日期：2026 年 9 月 25 日之后，所有运行过时版本的自托管 Runner 将无法再接收任何新的 CI/CD 任务。在此之前，从 9 月 7 日开始将进行多次 brownout 测试，具体日期为 9 月 7 日、9 日、11 日、14 日、16 日和 18 日。在这些测试日子里，Config 和 Runtime 相关的 outdated runner 既不</description>
    </item>
    <item>
      <title>Android 多渠道打包实战：Gradle 配置、性能调优与 CI/CD 落地</title>
      <link>https://index.zshipu.com/ai001/post/20260904/Android-%E5%A4%9A%E6%B8%A0%E9%81%93%E6%89%93%E5%8C%85%E5%AE%9E%E6%88%98Gradle-%E9%85%8D%E7%BD%AE%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98%E4%B8%8E-CICD-%E8%90%BD%E5%9C%B0/</link>
      <pubDate>Fri, 04 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260904/Android-%E5%A4%9A%E6%B8%A0%E9%81%93%E6%89%93%E5%8C%85%E5%AE%9E%E6%88%98Gradle-%E9%85%8D%E7%BD%AE%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98%E4%B8%8E-CICD-%E8%90%BD%E5%9C%B0/</guid>
      <description>Android 应用需要为不同应用市场、测试环境或灰度发布构建不同 APK 版本，这些版本可能有着不同的包名和服务端地址。手动处理这些差异不仅效率低下，还容易在发布流程中引入错误，Gradle 的多渠道打包与构建优化正是解决这一痛点的关键。 多渠道需求源于市场、测试和灰度发布的版本差异 国内 Android 开发者面临的应</description>
    </item>
    <item>
      <title>检测system()调用不难，构建可信仓库安全扫描器却极难</title>
      <link>https://index.zshipu.com/ai001/post/20260902/%E6%A3%80%E6%B5%8Bsystem%E8%B0%83%E7%94%A8%E4%B8%8D%E9%9A%BE%E6%9E%84%E5%BB%BA%E5%8F%AF%E4%BF%A1%E4%BB%93%E5%BA%93%E5%AE%89%E5%85%A8%E6%89%AB%E6%8F%8F%E5%99%A8%E5%8D%B4%E6%9E%81%E9%9A%BE/</link>
      <pubDate>Wed, 02 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260902/%E6%A3%80%E6%B5%8Bsystem%E8%B0%83%E7%94%A8%E4%B8%8D%E9%9A%BE%E6%9E%84%E5%BB%BA%E5%8F%AF%E4%BF%A1%E4%BB%93%E5%BA%93%E5%AE%89%E5%85%A8%E6%89%AB%E6%8F%8F%E5%99%A8%E5%8D%B4%E6%9E%81%E9%9A%BE/</guid>
      <description>检测system()调用不难，构建可信仓库安全扫描器却极难 检测system()调用或硬编码密钥并不难，作者用C++17无第三方运行时依赖构建仓库安全分析器时发现，真正的难点在于把多个扫描器整合成一个能理解仓库、解释风险、给出下一步建议、生成机器可读报告，并在违反安全策略时让CI管</description>
    </item>
    <item>
      <title>修复README错别字却要等25分钟：这些CI/CD错误正悄然拖慢团队部署</title>
      <link>https://index.zshipu.com/ai001/post/20260831/%E4%BF%AE%E5%A4%8DREADME%E9%94%99%E5%88%AB%E5%AD%97%E5%8D%B4%E8%A6%81%E7%AD%8925%E5%88%86%E9%92%9F%E8%BF%99%E4%BA%9BCICD%E9%94%99%E8%AF%AF%E6%AD%A3%E6%82%84%E7%84%B6%E6%8B%96%E6%85%A2%E5%9B%A2%E9%98%9F%E9%83%A8%E7%BD%B2/</link>
      <pubDate>Mon, 31 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260831/%E4%BF%AE%E5%A4%8DREADME%E9%94%99%E5%88%AB%E5%AD%97%E5%8D%B4%E8%A6%81%E7%AD%8925%E5%88%86%E9%92%9F%E8%BF%99%E4%BA%9BCICD%E9%94%99%E8%AF%AF%E6%AD%A3%E6%82%84%E7%84%B6%E6%8B%96%E6%85%A2%E5%9B%A2%E9%98%9F%E9%83%A8%E7%BD%B2/</guid>
      <description>修复一个README里的错别字，流水线却跑了25分钟才部署成功。这不是正常现象，而是CI/CD管道出了问题。大多数团队只是注意到部署感觉慢，却没意识到这是可以优化的症状。文章列出了按时间消耗排序的常见错误，第一个就是每次变更都运行完整测试套件。 这些错误看似细微，却在每次提交后默默</description>
    </item>
    <item>
      <title>零美元代码审查流水线：免费模型加自托管服务器实现PR自动检查</title>
      <link>https://index.zshipu.com/ai001/post/20260830/%E9%9B%B6%E7%BE%8E%E5%85%83%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5%E6%B5%81%E6%B0%B4%E7%BA%BF%E5%85%8D%E8%B4%B9%E6%A8%A1%E5%9E%8B%E5%8A%A0%E8%87%AA%E6%89%98%E7%AE%A1%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%AE%9E%E7%8E%B0PR%E8%87%AA%E5%8A%A8%E6%A3%80%E6%9F%A5/</link>
      <pubDate>Sun, 30 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260830/%E9%9B%B6%E7%BE%8E%E5%85%83%E4%BB%A3%E7%A0%81%E5%AE%A1%E6%9F%A5%E6%B5%81%E6%B0%B4%E7%BA%BF%E5%85%8D%E8%B4%B9%E6%A8%A1%E5%9E%8B%E5%8A%A0%E8%87%AA%E6%89%98%E7%AE%A1%E6%9C%8D%E5%8A%A1%E5%99%A8%E5%AE%9E%E7%8E%B0PR%E8%87%AA%E5%8A%A8%E6%A3%80%E6%9F%A5/</guid>
      <description>一个代码审查机器人每处理一个pull request零美元，却能捕获缺失的测试、死代码和错误处理问题。MonkeyCode开源AI编码助手通过免费模型和免费服务器选项实现这一流水线，无需信用卡。另一个真实案例显示，同一免费组合还能找出AI生成的C++函数返回局部变量引用的dangl</description>
    </item>
    <item>
      <title>AI代理忽略工具报错怎么办？在CI中自动捕获这类缺陷</title>
      <link>https://index.zshipu.com/ai001/post/20260817/AI%E4%BB%A3%E7%90%86%E5%BF%BD%E7%95%A5%E5%B7%A5%E5%85%B7%E6%8A%A5%E9%94%99%E6%80%8E%E4%B9%88%E5%8A%9E%E5%9C%A8CI%E4%B8%AD%E8%87%AA%E5%8A%A8%E6%8D%95%E8%8E%B7%E8%BF%99%E7%B1%BB%E7%BC%BA%E9%99%B7/</link>
      <pubDate>Mon, 17 Aug 2026 00:00:00 +0000</pubDate>
      <guid>https://index.zshipu.com/ai001/post/20260817/AI%E4%BB%A3%E7%90%86%E5%BF%BD%E7%95%A5%E5%B7%A5%E5%85%B7%E6%8A%A5%E9%94%99%E6%80%8E%E4%B9%88%E5%8A%9E%E5%9C%A8CI%E4%B8%AD%E8%87%AA%E5%8A%A8%E6%8D%95%E8%8E%B7%E8%BF%99%E7%B1%BB%E7%BC%BA%E9%99%B7/</guid>
      <description>问题：代理对工具报错视而不见 假设你发布了一个AI代理，它负责调用工具、读取结果、继续调用、最终给出答案。大多数时候一切正常，直到某个用户报告异常。你打开运行轨迹，发现charge_card工具返回了402错误，而代理没有停下，反而继续执行，最后告诉客户订单已发货。 这不是传统意义上</description>
    </item>
  </channel>
</rss>
