在您重试主题之前让自由模式 CI 工作可以重放

2026年8月15日3 次浏览来源:Dev.to阅读原文

重试陷阱 A 免费模式 CI 任务在超时失败 。

你点击重试。

整个输油管开始于:出站,建设,依赖,模式调用.

这就是陷阱。

为什么重操旧业?

输油管的再试不会隔离出平板步骤。

这让小问题变得昂贵。

我想要一个工作流程,只重播模型调用,而不是整个管道.

所以我让每个免费的模特儿 都留下了一张小唱片 记录有两半:输入信封和输出散列.

如果工作失败,我可以对同一模型重放输入,比较输出散列.

没有全管复通.

披露:这篇文章是作为MonkeyCode产品推广的一部分而编写的.

我使用MonkeyCode的免费模式访问模式步骤及其免费服务器选项作为小回放商店.

我不假设这里有精确的配额,模型名称,或可用窗口.

该图案与任何免费的HTTP模型端点和任何微小的钥匙价值商店或CI文物相配合.

为什么一个散列而不是全速的全速日志是有用的,直到它们不是。

一个免费的模型任务可能会收到合并请求的片段,错误消息,或者环境变量.

在CI日志中存储原始文本,可以不慎泄露来源或秘密.

将散列和回放输入存储在锁定的文物中,风险下降.

散列也给了我一个便宜的比较目标 我无需解释整个答复是为了看到一个终点有所改变。

我只需要字节级的平等 记录形状 每一次模型呼叫, 我省下下面的字段。 request id:取自于模型的散列,即时散列和时间戳. proo hash: 已规范的快取的散列 。

响应 hash:原始响应的散列.

状态:原调用时的HTTP状态.

字节:反应的长度.

精确的散列算法比两边使用相同的算法要少.

我使用SHA -256,因为它到处都有。

我负责两个工作 第一个工作是调用模型,并将记录发布到免费服务器.

第二个工作是手动的,只重放所录入的输入.

手工工作是有趣的部分。

它让我问一个问题:这个精确的输入能否再次产生同样的输出?

如果答案是否定的,我会停下来检查。

模型调用脚本 这个片段是一个紧凑的参考,而不是生产客户端.

错误处理是故意最小化的,所以流量是可见的.

重放输入被存储在CI文物中.

反应散列被存储在自由服务器上.

这种分拆使原始的快取出服务器,并保持比较便宜.

重放检查 回放工作读取了被保存的文物,并再次叫出模型来.

匹配散列表示端点返回字节-等同输出.

一个不匹配表示模型,终点,或输入正常化改变.

这是一个值得追求的信号。

这里有一个快速的决定桌。

情况 我所做的HTTP 429或超时退后重试;在重放检查模型或端点漂移散列匹配后,不要比较散列不匹配,但下游测试仍然无法调试代码和配置,而模型重放时间不把它当作能力问题处理,即时问题Hashing不会原谅非决定性输出.

如果模型返回一个时间戳,一个ID,或者随机格式,同样的输入会产生不同的散列.

散列前的规范化:脱去时间戳,ID,并尽可能后入白地.

利率限额仍然存在。

如果原调和回放都打出相同的自由级盖子,你会看到超时而非漂移.

与响应散列分开记录 HTTP 状态 。

否则,一个429看起来像模型漂移。

此外,字节平等没有用处。

自由端点可以改变它的响应格式而不会改变意义.

散列只证明准确的可复制性,而不是证明答案是正确的.

如果每个模式调用都已经很便宜,有天分,又能容忍失败,谁就不应该使用这个跳过.

如果你的球队可以跳过它

分享