Chainlink Local CRE Mixed-Env 拓扑用 2-2 双版本节点提前捕获非确定性与跨版本不兼容【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlinkMixed-env 是 Chainlink 仓库中 Local CRE链上计算执行环境Chainlink Runtime Environment面向 CI 的一种测试模式它在同一个 DON去中心化预言机网络里同时运行两个代码版本——一半节点使用 PR 分支构建的镜像另一半使用 PR 所基于的基线分支通常是develop构建的镜像只要两半节点在任何环节产生分歧测试就直接判失败。其核心价值是把合并后才暴露的非确定性问题和滚动升级时新旧节点互相不兼容提前到合并之前发现。读完本文你将掌握 mixed-env 的 2-2 拓扑结构、非确定性日志标记的含义、CI 合并门禁的运作方式以及如何在本地完整复现这套双镜像环境。为什么需要 mixed-envDON 的一致性假设DON 能正常工作前提是所有节点对相同输入计算出相同结果。一旦某个改动让节点产生不同的共识报告consensus report或不同节点对同一个跨 DON 请求/响应返回了不同载荷DON 就无法达成一致。这种问题在单版本环境中永远不会暴露——因为所有节点跑的是同一份代码行为完全一致。传统上这类问题要等到合并之后甚至在滚动升级期间新旧节点并排运行时才会浮现。Mixed-env 的做法是主动把旧版develop和新版PR节点放进同一个 DON让任何分歧都以 CI 检查失败的形式直接呈现而不是成为生产事故。它运行的拓扑2-2 拆分Mixed-env 采用标准的 capabilities 拓扑对应 workflow-gateway-capabilities-don唯一区别是每个多节点 DON 都被按2-2拆到两个镜像上DON节点数镜像拆分workflow42 × PR · 2 × developchain-capcapabilities42 × PR · 2 × developvault42 × PR · 2 × developbootstrap/gateway1developworkflow DON chain-cap / vault DON ┌──────┬──────┬──────┬──────┐ ┌──────┬──────┬──────┬──────┐ │ PR │ PR │ dev │ dev │ │ PR │ PR │ dev │ dev │ └──────┴──────┴──────┴──────┘ └──────┴──────┴──────┴──────┘PR image 从你的分支构建出的 Chainlink 节点镜像。baseline image 你的 PR 将要合并进入的分支的精确 commit——也就是 CI 自动合并的基座。对于目标为develop的 PR它是你分支所基于的那个developcommit对于目标为发布分支如release/2.57.1的 PR则是该发布 commit。由于它精确对应 PR 镜像的派生源头两半节点只差你 PR 的改动基线分支自身的历史变更不会造成误报。如果该基线镜像尚未发布回退策略取决于基线分支基座是develop→ 回退到最近缓存的developnightly构建。栈式 PR基座是最终指向develop的另一个特性分支→ 同样回退到develop nightly。此时对比的是整个栈父分支 你的 PR与develop的差异因此父分支对运行时行为的改动也可能在此暴露——这本身就是一个真实潜在的、父分支合并时同样会被捕获的非确定性信号若属预期行为可用skip-mixed-env标签 跳过。发布分支如release/2.57.1→跳过并记录警告日志。因为不存在正确的替身develop nightly 属于错误分支会让整个 release↔develop 的差异淹没本次运行发布分支的提交不像develop那样被强制构建其分支尖端镜像往往缺失即便存在发布 PR 也不会获得这项检查。链、capabilities、端口等其余一切均与常规拓扑完全一致只有每个节点的镜像不同。这一点在拓扑模板 mixed-env-don.toml.tmpl 中有直接体现workflow与capabilities两个 nodeset 均声明nodes 4、override_mode each然后通过 4 条node_specs将前两个节点指定为${CRE_PR_IMAGE}、后两个节点指定为${CRE_BASELINE_IMAGE}而bootstrap-gateway节点只跑 1 个节点且固定使用${CRE_BASELINE_IMAGE}——模板注释明确说明该节点不运行 reporting 插件其代码版本不影响非确定性信号因此保留在 develop 上以维持稳定。它检查什么三层日志标记在常规 smoke 测试运行期间mixed-env 会监视每个节点的日志寻找 PR 节点与 develop 节点分歧的典型信号。只要以下标记出现一次测试即标记为失败失败原因为Non-Determinism introduced层级命中含义监视的日志行共识OCR同一轮中节点生成了不同的报告This is commonly caused by non-determinism跨 DON 请求相同请求、不同节点载荷不同received messages with the same id and different payloads跨 DON 响应同一请求不同节点返回了不同响应received multiple unique responses for the same request/response quorum unreachable这些日志行在所有节点运行相同代码时是静默的因此单次出现就是一个可靠信号PR 改变了develop所不同意的行为。这一组标记在源码中是单一事实来源定义于 nondeterminism_scan.go 的NonDeterminismNeedles变量var NonDeterminismNeedles []string{ // libocr OCR3 共识某个对端的 report/commit 签名未能通过本节点自行计算报告的验证 This is commonly caused by non-determinism, // DON2DON 远程能力请求聚合服务端 received messages with the same id and different payloads, // DON2DON 远程能力响应聚合客户端 received multiple unique responses for the same request, response quorum unreachable, }注释揭示了每个标记的底层含义OCR3 共识层的标记对应 report-attestation 与 commit 阶段中某个对等节点的报告/提交签名未能通过本节点自行计算出的报告验证另外两个标记分别对应 DON2DON 远程能力调用在服务端的请求聚合与客户端的响应聚合。扫描器ScanContainersForNeedles通过framework.StreamContainerLogs流式读取所有 Docker 容器的 stdout/stderr逐容器做子串匹配返回(容器名, 标记)命中列表对无法读取日志的容器仅记录警告并跳过best-effort不会因为日志不可读而误判失败。能捕获什么、不能捕获什么能捕获使节点计算出与develop不同的共识报告的改动——序列化/编码变化、新增或重排字段、map 遍历顺序问题、舍入误差以及任何非确定性逻辑。改变跨 DON 请求或响应载荷的改动。会破坏新旧混合部署如滚动升级的向后不兼容改动。不能捕获值得了解只在真正执行共识或跨 DON 能力调用的测试中才会触发。纯 gateway/HTTP 路径不会触发。它会标记任何与develop的分歧——包括有意的报告/载荷变更。这类变更本身是真实的不兼容如果改动是深思熟虑的、会安全灰度发布应使用skip-mixed-env标签 绕过检查而不是修复它。它对比的是你 PR 所基于的那个developcommit不是最新的develop。因此只与你在分支之后合入的developcommit 冲突的改动由 nightly 全矩阵扫描其固定最新develop捕获而非每个 PR 各自运行。想让信号最紧应让你的分支保持相对较新。何时运行CI 自动化与合并门禁在 CI 中mixed-env 在自己的 workflow.github/workflows/cre-mixed-env-tests.yaml与cre-system-tests.yaml分离以保持后者简单里对影响 CRE 的 PR 自动运行执行 OCR3/DON2DON 权重最高的测试——Test_CRE_V2_Suite_Bucket_A、Test_CRE_V2_Suite_Bucket_B以及Test_CRE_V2_EVM_Read_*套件。PR 镜像和 develop 镜像per-PR 与 nightly都已经构建好了因此不会新增任何额外的镜像构建。测试结束后一个独立的Check for non-determinism步骤会扫描存活的节点容器一旦发现标记就使 job 失败——该步骤与自动隔离auto-quarantine的测试步骤分开确保失败不会被吞掉。从 integration-tests.yml 的源码可以看出这套门禁的完整接线run-core-cre-mixed-env-testsjob约 L511通过uses: ./.github/workflows/cre-mixed-env-tests.yaml复用子 workflow并由run-core-cre-e2e-tests-setup输出的run-mixed-env条件控制是否运行skip-mixed-env标签由 labels job 检测后传入SKIP_MIXED_ENV_LABEL_FOUND。聚合门禁check-e2e-test-results约 L725名为ETH Smoke Tests在其needs列表中包含run-core-cre-mixed-env-tests随后对每个结果调用check_resultfailure与cancelled直接报错并返回失败而skipped只输出::warning::级别的警告、不阻断合并——这正是标签绕过能解锁合并的机制来源。必需检查与紧急绕过Mixed-env 是必需检查它接入ETH Smoke Tests合并门禁即check-e2e-test-results位于 .github/workflows/integration-tests.yml因此非确定性失败会阻止合并。合法跳过的运行非 CRE 的 PR或没有基线镜像的发布分支 PR——见上文按非阻断警告处理不算失败。紧急情况下按优先级依次选择绕过方式skip-mixed-envPR 标签自助给 PR 打上该标签并重跑 CI。mixed-env job 会被跳过门禁将其视为警告合并随即解锁——无需管理员介入。与 E2E 回归测试一致mixed-env 不跑在 merge queue 中因此该绕过在队列中同样生效。适用于检查正确标记的有意、会安全灰度发布的改动或基础设施问题排查期间需要解锁的场景。管理员 / ruleset 绕过仓库管理员以及 ruleset 的绕过执行者可以直接越过失败的必需检查合并。拆除门禁若要长期禁用将run-core-cre-mixed-env-tests从check-e2e-test-resultsjob 的needs列表及其check_result检查行中移除。注意CRE_NONDETERMINISM_CHECK环境变量只在本地运行时切换测试内的日志扫描开关它不是 CI 合并杠杆。CI 中请使用标签。在本地运行Mixed-env 对比的是两个预构建镜像因此需要用两个镜像引用渲染拓扑并在启动环境时不设置CTF_CHAINLINK_IMAGE非空值会强制所有节点使用单一镜像破坏混合。cd core/scripts/cre/environment # 1. 用两个镜像渲染拓扑你的构建 develop 构建。 CRE_PR_IMAGEyour image CRE_BASELINE_IMAGEdevelop image \ ./configs/render-mixed-env.sh # 2. 基于渲染出的配置启动——不要设置 CTF_CHAINLINK_IMAGE。 CTF_CONFIGSconfigs/mixed-env-don.toml go run . env start渲染脚本 render-mixed-env.sh 的源码揭示了几个关键细节它通过set -euo pipefail强制要求CRE_PR_IMAGE与CRE_BASELINE_IMAGE两个环境变量非空pull_image默认true--local参数将其翻转为false渲染使用envsubst依赖gettext包并仅替换${CRE_PR_IMAGE} ${CRE_BASELINE_IMAGE} ${CRE_PULL_IMAGE}三个变量避免误伤模板中的其他$脚本会遍历目录下所有mixed-env-*.toml.tmpl模板逐一渲染每个渲染到去除.tmpl后缀的同名文件因此新增 mixed-env 拓扑无需改动脚本。渲染产物configs/mixed-env-don.toml被 gitignore不会污染仓库。用本地镜像运行默认渲染出的拓扑设置pull_image true环境会从镜像仓库拉取每个节点镜像。如果你的两个镜像都是本地构建拉取会失败——裸引用如chainlink:develop会解析到 Docker Hub而那里并不存在同名公共仓库pull access denied for chainlink。传入--local渲染出pull_image false的配置环境就会直接使用本地 Docker daemon 中已有的镜像。如果你之前运行过 Local CRE当前分支已经被构建为chainlink-tmp:latest。要获得本地 develop 镜像构建一个 tag 为develop的镜像DOCKER_TAGdevelop make docker确认两个镜像都存在docker image ls | grep chainlink # chainlink-tmp:latest # chainlink:develop然后用--local渲染并按常规方式启动CRE_PR_IMAGEchainlink-tmp:latest CRE_BASELINE_IMAGEchainlink:develop \ ./configs/render-mixed-env.sh --local CTF_CONFIGSconfigs/mixed-env-don.toml go run . env start随后在检查激活的状态下运行 smoke 套件cd system-tests/tests TOPOLOGY_NAMEmixed-env go test ./smoke/cre -run ^Test_CRE_V2_Suite_Bucket_A$ -timeout 20m检查会自动开启当TOPOLOGY_NAME包含mixed-env或显式设置CRE_NONDETERMINISM_CHECKtrue时生效。测试结束后会扫描每个节点的日志单个标记就会使运行以Non-Determinism introduced失败并列出违规容器。底层实现检查如何穿透到测试与 CImixed-env 的本地检查与 CI 门禁共享同一套扫描逻辑避免在 bash 中重复实现smoke 套件内TestMain见 nondeterminism_check_test.go在m.Run()结束之后、共享容器仍然存活时调用reportNonDeterminism()即使所有测试都通过只要发现标记就把退出码改为 1。启用条件是CRE_NONDETERMINISM_CHECKtrue或TOPOLOGY_NAME含mixed-env单镜像运行永远不会产生这些日志行无需扫描。失败信息以常量nonDeterminismFailurePrefix Non-Determinism introduced前缀输出确保 CI 日志/JUnit 输出中的失败原因无歧义。CI 门禁独立命令 mixed-env-nondeterminism-check/main.go 复用helpers.ScanContainersForNeedles与同一份NonDeterminismNeedles命中时以::error::注解输出并os.Exit(1)读取不到容器日志被视为基础设施问题而非非确定性信号只打警告不失败与套件内扫描保持一致。单一事实来源两份逻辑都引用 nondeterminism_scan.go 中的NonDeterminismNeedles新增或调整标记只需改一处。总结mixed-env 的适用边界Mixed-env 是把版本升级事故前置到 CI的一种务实设计以最小的拓扑改动仅替换每节点镜像换取对共识报告、跨 DON 载荷与向后兼容性的系统性回归探测。它不能替代常规的功能测试——它只在共识/跨 DON 路径被实际触发时才产生信号它也会如实标记有意的行为变更此时用标签绕过而非修改代码。理解它的回退镜像策略与合并门禁接线integration-tests.yml 中的run-core-cre-mixed-env-tests与check-e2e-test-results你就能在提交 CRE 相关 PR 时准确解读检查结果并在本地用render-mixed-env.sh --local快速复现同样的双版本对比环境。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Chainlink Local CRE Mixed-Env 拓扑：用 2-2 双版本节点提前捕获非确定性与跨版本不兼容
Chainlink Local CRE Mixed-Env 拓扑用 2-2 双版本节点提前捕获非确定性与跨版本不兼容【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlinkMixed-env 是 Chainlink 仓库中 Local CRE链上计算执行环境Chainlink Runtime Environment面向 CI 的一种测试模式它在同一个 DON去中心化预言机网络里同时运行两个代码版本——一半节点使用 PR 分支构建的镜像另一半使用 PR 所基于的基线分支通常是develop构建的镜像只要两半节点在任何环节产生分歧测试就直接判失败。其核心价值是把合并后才暴露的非确定性问题和滚动升级时新旧节点互相不兼容提前到合并之前发现。读完本文你将掌握 mixed-env 的 2-2 拓扑结构、非确定性日志标记的含义、CI 合并门禁的运作方式以及如何在本地完整复现这套双镜像环境。为什么需要 mixed-envDON 的一致性假设DON 能正常工作前提是所有节点对相同输入计算出相同结果。一旦某个改动让节点产生不同的共识报告consensus report或不同节点对同一个跨 DON 请求/响应返回了不同载荷DON 就无法达成一致。这种问题在单版本环境中永远不会暴露——因为所有节点跑的是同一份代码行为完全一致。传统上这类问题要等到合并之后甚至在滚动升级期间新旧节点并排运行时才会浮现。Mixed-env 的做法是主动把旧版develop和新版PR节点放进同一个 DON让任何分歧都以 CI 检查失败的形式直接呈现而不是成为生产事故。它运行的拓扑2-2 拆分Mixed-env 采用标准的 capabilities 拓扑对应 workflow-gateway-capabilities-don唯一区别是每个多节点 DON 都被按2-2拆到两个镜像上DON节点数镜像拆分workflow42 × PR · 2 × developchain-capcapabilities42 × PR · 2 × developvault42 × PR · 2 × developbootstrap/gateway1developworkflow DON chain-cap / vault DON ┌──────┬──────┬──────┬──────┐ ┌──────┬──────┬──────┬──────┐ │ PR │ PR │ dev │ dev │ │ PR │ PR │ dev │ dev │ └──────┴──────┴──────┴──────┘ └──────┴──────┴──────┴──────┘PR image 从你的分支构建出的 Chainlink 节点镜像。baseline image 你的 PR 将要合并进入的分支的精确 commit——也就是 CI 自动合并的基座。对于目标为develop的 PR它是你分支所基于的那个developcommit对于目标为发布分支如release/2.57.1的 PR则是该发布 commit。由于它精确对应 PR 镜像的派生源头两半节点只差你 PR 的改动基线分支自身的历史变更不会造成误报。如果该基线镜像尚未发布回退策略取决于基线分支基座是develop→ 回退到最近缓存的developnightly构建。栈式 PR基座是最终指向develop的另一个特性分支→ 同样回退到develop nightly。此时对比的是整个栈父分支 你的 PR与develop的差异因此父分支对运行时行为的改动也可能在此暴露——这本身就是一个真实潜在的、父分支合并时同样会被捕获的非确定性信号若属预期行为可用skip-mixed-env标签 跳过。发布分支如release/2.57.1→跳过并记录警告日志。因为不存在正确的替身develop nightly 属于错误分支会让整个 release↔develop 的差异淹没本次运行发布分支的提交不像develop那样被强制构建其分支尖端镜像往往缺失即便存在发布 PR 也不会获得这项检查。链、capabilities、端口等其余一切均与常规拓扑完全一致只有每个节点的镜像不同。这一点在拓扑模板 mixed-env-don.toml.tmpl 中有直接体现workflow与capabilities两个 nodeset 均声明nodes 4、override_mode each然后通过 4 条node_specs将前两个节点指定为${CRE_PR_IMAGE}、后两个节点指定为${CRE_BASELINE_IMAGE}而bootstrap-gateway节点只跑 1 个节点且固定使用${CRE_BASELINE_IMAGE}——模板注释明确说明该节点不运行 reporting 插件其代码版本不影响非确定性信号因此保留在 develop 上以维持稳定。它检查什么三层日志标记在常规 smoke 测试运行期间mixed-env 会监视每个节点的日志寻找 PR 节点与 develop 节点分歧的典型信号。只要以下标记出现一次测试即标记为失败失败原因为Non-Determinism introduced层级命中含义监视的日志行共识OCR同一轮中节点生成了不同的报告This is commonly caused by non-determinism跨 DON 请求相同请求、不同节点载荷不同received messages with the same id and different payloads跨 DON 响应同一请求不同节点返回了不同响应received multiple unique responses for the same request/response quorum unreachable这些日志行在所有节点运行相同代码时是静默的因此单次出现就是一个可靠信号PR 改变了develop所不同意的行为。这一组标记在源码中是单一事实来源定义于 nondeterminism_scan.go 的NonDeterminismNeedles变量var NonDeterminismNeedles []string{ // libocr OCR3 共识某个对端的 report/commit 签名未能通过本节点自行计算报告的验证 This is commonly caused by non-determinism, // DON2DON 远程能力请求聚合服务端 received messages with the same id and different payloads, // DON2DON 远程能力响应聚合客户端 received multiple unique responses for the same request, response quorum unreachable, }注释揭示了每个标记的底层含义OCR3 共识层的标记对应 report-attestation 与 commit 阶段中某个对等节点的报告/提交签名未能通过本节点自行计算出的报告验证另外两个标记分别对应 DON2DON 远程能力调用在服务端的请求聚合与客户端的响应聚合。扫描器ScanContainersForNeedles通过framework.StreamContainerLogs流式读取所有 Docker 容器的 stdout/stderr逐容器做子串匹配返回(容器名, 标记)命中列表对无法读取日志的容器仅记录警告并跳过best-effort不会因为日志不可读而误判失败。能捕获什么、不能捕获什么能捕获使节点计算出与develop不同的共识报告的改动——序列化/编码变化、新增或重排字段、map 遍历顺序问题、舍入误差以及任何非确定性逻辑。改变跨 DON 请求或响应载荷的改动。会破坏新旧混合部署如滚动升级的向后不兼容改动。不能捕获值得了解只在真正执行共识或跨 DON 能力调用的测试中才会触发。纯 gateway/HTTP 路径不会触发。它会标记任何与develop的分歧——包括有意的报告/载荷变更。这类变更本身是真实的不兼容如果改动是深思熟虑的、会安全灰度发布应使用skip-mixed-env标签 绕过检查而不是修复它。它对比的是你 PR 所基于的那个developcommit不是最新的develop。因此只与你在分支之后合入的developcommit 冲突的改动由 nightly 全矩阵扫描其固定最新develop捕获而非每个 PR 各自运行。想让信号最紧应让你的分支保持相对较新。何时运行CI 自动化与合并门禁在 CI 中mixed-env 在自己的 workflow.github/workflows/cre-mixed-env-tests.yaml与cre-system-tests.yaml分离以保持后者简单里对影响 CRE 的 PR 自动运行执行 OCR3/DON2DON 权重最高的测试——Test_CRE_V2_Suite_Bucket_A、Test_CRE_V2_Suite_Bucket_B以及Test_CRE_V2_EVM_Read_*套件。PR 镜像和 develop 镜像per-PR 与 nightly都已经构建好了因此不会新增任何额外的镜像构建。测试结束后一个独立的Check for non-determinism步骤会扫描存活的节点容器一旦发现标记就使 job 失败——该步骤与自动隔离auto-quarantine的测试步骤分开确保失败不会被吞掉。从 integration-tests.yml 的源码可以看出这套门禁的完整接线run-core-cre-mixed-env-testsjob约 L511通过uses: ./.github/workflows/cre-mixed-env-tests.yaml复用子 workflow并由run-core-cre-e2e-tests-setup输出的run-mixed-env条件控制是否运行skip-mixed-env标签由 labels job 检测后传入SKIP_MIXED_ENV_LABEL_FOUND。聚合门禁check-e2e-test-results约 L725名为ETH Smoke Tests在其needs列表中包含run-core-cre-mixed-env-tests随后对每个结果调用check_resultfailure与cancelled直接报错并返回失败而skipped只输出::warning::级别的警告、不阻断合并——这正是标签绕过能解锁合并的机制来源。必需检查与紧急绕过Mixed-env 是必需检查它接入ETH Smoke Tests合并门禁即check-e2e-test-results位于 .github/workflows/integration-tests.yml因此非确定性失败会阻止合并。合法跳过的运行非 CRE 的 PR或没有基线镜像的发布分支 PR——见上文按非阻断警告处理不算失败。紧急情况下按优先级依次选择绕过方式skip-mixed-envPR 标签自助给 PR 打上该标签并重跑 CI。mixed-env job 会被跳过门禁将其视为警告合并随即解锁——无需管理员介入。与 E2E 回归测试一致mixed-env 不跑在 merge queue 中因此该绕过在队列中同样生效。适用于检查正确标记的有意、会安全灰度发布的改动或基础设施问题排查期间需要解锁的场景。管理员 / ruleset 绕过仓库管理员以及 ruleset 的绕过执行者可以直接越过失败的必需检查合并。拆除门禁若要长期禁用将run-core-cre-mixed-env-tests从check-e2e-test-resultsjob 的needs列表及其check_result检查行中移除。注意CRE_NONDETERMINISM_CHECK环境变量只在本地运行时切换测试内的日志扫描开关它不是 CI 合并杠杆。CI 中请使用标签。在本地运行Mixed-env 对比的是两个预构建镜像因此需要用两个镜像引用渲染拓扑并在启动环境时不设置CTF_CHAINLINK_IMAGE非空值会强制所有节点使用单一镜像破坏混合。cd core/scripts/cre/environment # 1. 用两个镜像渲染拓扑你的构建 develop 构建。 CRE_PR_IMAGEyour image CRE_BASELINE_IMAGEdevelop image \ ./configs/render-mixed-env.sh # 2. 基于渲染出的配置启动——不要设置 CTF_CHAINLINK_IMAGE。 CTF_CONFIGSconfigs/mixed-env-don.toml go run . env start渲染脚本 render-mixed-env.sh 的源码揭示了几个关键细节它通过set -euo pipefail强制要求CRE_PR_IMAGE与CRE_BASELINE_IMAGE两个环境变量非空pull_image默认true--local参数将其翻转为false渲染使用envsubst依赖gettext包并仅替换${CRE_PR_IMAGE} ${CRE_BASELINE_IMAGE} ${CRE_PULL_IMAGE}三个变量避免误伤模板中的其他$脚本会遍历目录下所有mixed-env-*.toml.tmpl模板逐一渲染每个渲染到去除.tmpl后缀的同名文件因此新增 mixed-env 拓扑无需改动脚本。渲染产物configs/mixed-env-don.toml被 gitignore不会污染仓库。用本地镜像运行默认渲染出的拓扑设置pull_image true环境会从镜像仓库拉取每个节点镜像。如果你的两个镜像都是本地构建拉取会失败——裸引用如chainlink:develop会解析到 Docker Hub而那里并不存在同名公共仓库pull access denied for chainlink。传入--local渲染出pull_image false的配置环境就会直接使用本地 Docker daemon 中已有的镜像。如果你之前运行过 Local CRE当前分支已经被构建为chainlink-tmp:latest。要获得本地 develop 镜像构建一个 tag 为develop的镜像DOCKER_TAGdevelop make docker确认两个镜像都存在docker image ls | grep chainlink # chainlink-tmp:latest # chainlink:develop然后用--local渲染并按常规方式启动CRE_PR_IMAGEchainlink-tmp:latest CRE_BASELINE_IMAGEchainlink:develop \ ./configs/render-mixed-env.sh --local CTF_CONFIGSconfigs/mixed-env-don.toml go run . env start随后在检查激活的状态下运行 smoke 套件cd system-tests/tests TOPOLOGY_NAMEmixed-env go test ./smoke/cre -run ^Test_CRE_V2_Suite_Bucket_A$ -timeout 20m检查会自动开启当TOPOLOGY_NAME包含mixed-env或显式设置CRE_NONDETERMINISM_CHECKtrue时生效。测试结束后会扫描每个节点的日志单个标记就会使运行以Non-Determinism introduced失败并列出违规容器。底层实现检查如何穿透到测试与 CImixed-env 的本地检查与 CI 门禁共享同一套扫描逻辑避免在 bash 中重复实现smoke 套件内TestMain见 nondeterminism_check_test.go在m.Run()结束之后、共享容器仍然存活时调用reportNonDeterminism()即使所有测试都通过只要发现标记就把退出码改为 1。启用条件是CRE_NONDETERMINISM_CHECKtrue或TOPOLOGY_NAME含mixed-env单镜像运行永远不会产生这些日志行无需扫描。失败信息以常量nonDeterminismFailurePrefix Non-Determinism introduced前缀输出确保 CI 日志/JUnit 输出中的失败原因无歧义。CI 门禁独立命令 mixed-env-nondeterminism-check/main.go 复用helpers.ScanContainersForNeedles与同一份NonDeterminismNeedles命中时以::error::注解输出并os.Exit(1)读取不到容器日志被视为基础设施问题而非非确定性信号只打警告不失败与套件内扫描保持一致。单一事实来源两份逻辑都引用 nondeterminism_scan.go 中的NonDeterminismNeedles新增或调整标记只需改一处。总结mixed-env 的适用边界Mixed-env 是把版本升级事故前置到 CI的一种务实设计以最小的拓扑改动仅替换每节点镜像换取对共识报告、跨 DON 载荷与向后兼容性的系统性回归探测。它不能替代常规的功能测试——它只在共识/跨 DON 路径被实际触发时才产生信号它也会如实标记有意的行为变更此时用标签绕过而非修改代码。理解它的回退镜像策略与合并门禁接线integration-tests.yml 中的run-core-cre-mixed-env-tests与check-e2e-test-results你就能在提交 CRE 相关 PR 时准确解读检查结果并在本地用render-mixed-env.sh --local快速复现同样的双版本对比环境。【免费下载链接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation项目地址: https://gitcode.com/GitHub_Trending/ch/chainlink创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考