返回首页
最新
DSCI 是一个持续集成（CI）管道框架，能够通过 Webhooks 与一些现有的 CI/CD 系统（如 Gitea、Forgejo、GitLab）集成，允许作者使用通用编程语言编写 CI/CD 代码。它为多种编程语言提供了软件开发工具包（SDK）。SDK 帮助处理输入参数、编写插件、在任务和作业之间传递结果、处理机密信息、启用自我测试等。
<p>目标受众 - 使用通用编程语言而非 YAML 的自托管 CI/CD 系统和 DevOps。
<p>文章链接 - https://github.com/melezhik/DSCI/blob/main/introduction.md
<p>声明 - 欢迎随时向我提问或提供建设性反馈 - 我是该工具的作者。
<p>谢谢！
我五岁的孩子正在学习阅读，我总是不得不说“抱歉，这个字母是静音的”和“不是，这些字母在这个单词中发出不同的声音”。<p>所以我创建了Ingglish——一种每个字母总是发出相同声音的英语。“ough”单独就有六种不同的发音（though, through, rough, cough, thought, bough）。在Ingglish中，每个字母只有一个发音，没有静音字母，没有例外。<p><pre><code> - 粘贴文本即可即时翻译
- 翻译任何网页，同时保留其布局
- Chrome扩展程序，让你在Ingglish中浏览网页
- 完全可逆——Ingglish文本可以转换回标准英语（不包括同音词）
</code></pre>
核心翻译器、DOM集成和网站都是开源的：<a href="https://github.com/ptarjan/ingglish" rel="nofollow">https://github.com/ptarjan/ingglish</a><p>我很想听听你的反馈！谢谢。
在你的持续集成（CI）管道中，每一个重试规则都是一种止痛药。它抑制了症状，而底层的破损代码库存却在不断增加，直到整个系统上瘾时，没人会感受到疼痛。
我看到了一篇在 Hacker News 上的帖子，完美地说明了这种模式：https://news.ycombinator.com/item?id=46967724
重试、隔离、增加等待时间——这些都不是解决方案。它们只是让 CI 暂时跳过错误。真正的问题是：有越来越多的破损代码在滋养你的管道，而没有机制让引入这些代码的人感受到痛苦。
两个相互强化的循环开始运作：
```
红色管道 --> <重试> --> 绿色构建
^ |
| （长期） |
| v
更多不稳定性 <---- 隐藏的错误积累
```
R1 “上瘾”：每次重试都让灯变绿。但隐藏的错误在底层积累，使系统变得更加不稳定，明天需要更多的重试。这是教科书式的“转移负担”，来自 Donella Meadows。
R2 “侵蚀”：因为你不信任 CI 的信号，你降低了标准。因为你降低了标准，更糟糕的代码被合并。信号变得更加不可靠。重复这个过程，直到你的管道变成装饰品。
原帖问 QA 和工程应该如何分担责任。这是个错误的问题。正确的问题是：如何让引入不稳定性的人感受到痛苦？
我也遇到了同样的障碍。
我构建了 CI，将 973 个 ROS 2 包移植到两个非官方支持的 Linux 发行版（openEuler + openKylin，RISC-V）。没有任何上游支持。
v1 - 粗暴探测。拉取所有 973 个包，让它们崩溃。597 个构建成功，214 个依赖缺口和 151 个失败被记录。这个管道并不是为了通过，而是为了让每一个隐藏的库存可见。
v2 - 验证引擎。先探测环境，在构建之前识别缺口。停止向管道输入垃圾。构建尝试减少，成功率提高。
v3 - 增量库存管理。将小批量问题隔离，一组一组地解决。减法，而不是加法。
我的系统也上瘾了。
在这里，我要自我反省。我的 CI 也有相同的模式。虚拟环境用来绕过依赖冲突。伪装规则用来伪装包的身份。都是权宜之计。
但我知道这些只是权宜之计。大多数团队并不知道。他们认为重试是解决方案。意识到上瘾和被其吞噬是两回事。
我可以识别出毒害你管道的库存。我可以设计反馈循环，让合适的人感受到痛苦。但我无法强迫一个组织去关心。这通常是实际的瓶颈——不是不稳定的测试，而是系统拒绝让任何人感受到后果。
代码库：https://github.com/Sebastianhayashi/the_adaptive_verification_engine