指南：環(huán)境生命周期、冒煙/回歸測試與自定義拓撲)
Chainlink 本地 CRE E2E 實戰(zhàn)指南環(huán)境生命周期、冒煙/回歸測試與自定義拓撲【免費下載鏈接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation項目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文面向需要在chainlink倉庫中本地開發(fā)、調試 CREChainlink Runtime Environment鏈上/鏈下工作流運行時的開發(fā)者和測試工程師系統(tǒng)講解如何在本地拉起完整的 CRE 環(huán)境、運行 CRE 冒煙/回歸端到端測試以及通過自定義拓撲覆蓋 limits、feature flags、capability 配置與user_config_overrides的完整方法。讀完本文你將掌握從env stop到env start的完整環(huán)境生命周期操作、默認拓撲下的測試執(zhí)行套路以及基于CTF_CONFIGS 拓撲 TOML 靈活定制測試場景的實戰(zhàn)技能。本文的核心依據是倉庫內 Agent Skill 文檔 docs/local-cre/agent-skills/local-cre-e2e/SKILL.md并輔以 Local CRE 環(huán)境 CLI 與 CRE 冒煙測試套件 的源碼佐證。適用范圍與基本假設這個 Skill 解決什么問題local-cre-e2e是一個面向 Agent 與開發(fā)者的操作技能說明適用于以下場景啟動、停止或重啟本地 CRE 環(huán)境在默認拓撲上運行 CRE 冒煙smoke或回歸regression端到端測試針對特定拓撲運行測試創(chuàng)建自定義拓撲以覆蓋 limits、flags、capability 配置或user_config_overrides。需要特別注意的是它面向的是Local CRE 系統(tǒng)級測試工作流不適用于普通單元測試。運行前提假設根據 SKILL.md使用該工作流需滿足四個前提倉庫根目錄是chainlink的檢出目錄即當前倉庫根本地 CRE 命令統(tǒng)一在core/scripts/cre/environment目錄下執(zhí)行CRE E2E 測試命令統(tǒng)一在system-tests/tests目錄下執(zhí)行除非明確知道 harness 支持隔離否則同一時間只應有一個活動的本地 CRE 環(huán)境——這是避免狀態(tài)串擾的關鍵紀律。從源碼看CLI 入口位于 core/scripts/cre/environment/main.go它把env、topology、examples、bs、obs五組子命令掛到根命令root.RootCmd上因此所有環(huán)境操作都通過go run . command [subcommand]的統(tǒng)一形態(tài)調用。默認工作流從清理到啟動一次本地 CRE第一步停止可能存在的舊環(huán)境每次開始前先徹底停止可能殘留的本地 CRE 環(huán)境避免新環(huán)境與舊狀態(tài)的端口、容器、狀態(tài)文件沖突cd core/scripts/cre/environment go run . env stop -a-a--all會連同所有額外服務一起停止。對應源碼見 environment.go 中stop子命令的定義其提示信息明確寫道All extra services: stop withgo run . env stop --all。第二步一次性準備環(huán)境如果環(huán)境尚未準備過或需要重新拉取/構建依賴鏡像先執(zhí)行一次設置cd core/scripts/cre/environment go run . env setupenv setup由configs/setup.toml驅動負責確保 Job Distributor、Chip Router、Chip Ingress、Chip Config 等托管鏡像就緒。它也可以顯式指定配置并跳過交互提示go run . env setup --config configs/setup.toml --no-prompt如果需要重建或重新拉取全部前置依賴env setup支持--purge需要計費billing資產時可加--with-billing詳見 docs/local-cre/getting-started/index.md。提示env setup并非每次都要跑。鏡像已經就位、只改拓撲 TOML 的情況下直接env start即可。SKILL.md 強調它是環(huán)境尚未準備時的一次性步驟。第三步啟動默認拓撲cd core/scripts/cre/environment go run . env startenv start默認讀取CTF_CONFIGS指向的拓撲 TOML未設置時使用默認拓撲workflow-gateway-capabilities-don.toml。對應源碼見 environment.go其中還包含對 Job Distributor 鏡像的存在性檢查environment.go若鏡像缺失會提示先執(zhí)行go run . env setup?？焖偕鲜謺r也可以一步到位使用--auto-setupgo run . env start --auto-setup第四步可選啟動可觀測性組件go run . obs up當你需要日志、追蹤或面板來調試工作流事件時用obs up拉起 observability 輔助棧。SKILL.md 特別指出當測試依賴真實 ChIP Ingress ?；蚰阆胗肦ed Panda Console調試工作流事件時在env start上加--with-chip-ingress-stack--with-beholder已廢棄deprecated等價行為請改用--with-chip-ingress-stack。為什么默認冒煙流程不建議開--with-chip-ingress-stackdocs/local-cre/system-tests/running-tests.md 給出了實現(xiàn)層面的原因大多數 CRE 冒煙測試會在默認 gRPC 端口50051上啟動 ChIP 測試 sinktest sink而 Chip Ingress 棧的 ChIP ingress 也綁定同一端口。兩者搶同一端口會導致測試 sink 啟動失敗。因此僅在以下情況才啟用該棧你在跑 Chip Ingress 棧專屬的覆蓋場景你需要用它做調試你通過--grpc-port給它換一個端口把默認50051留給測試 sink。Chip 相關組件的默認端口布局來自 docs/local-cre/environment/index.md50050Chip Router admin API50051Chip Router ingress gRPC50052chip-config50053真實 ChIP / Chip Ingress 棧 gRPC。補充本地源碼構建模式在默認拓撲基礎上如果你正在開發(fā) node 或某個 capabilitydocs/local-cre/environment/index.md 還提供了兩個高頻擴展 flag# 節(jié)點 全部 capability 都用本地工作樹構建含 observability go run . env start --with-observability --local-node --local-capabilities all # 節(jié)點用固定鏡像僅 cron evm 用本地構建覆蓋 go run . env start --local-capabilities cron,evm--local-node在宿主機交叉編譯本地 checkout 的 Chainlink 節(jié)點并烘焙進最小鏡像覆蓋拓撲中的docker_ctx/image--local-capabilities names|all從本地源碼構建指定 CRE capability 并注入節(jié)點未列出的 capability 保留鏡像內版本--capabilities-path dir本地 capabilities 倉庫位置默認$CRE_CAPABILITIES_PATH否則為~/go/src/github.com/smartcontractkit/capabilities--local-build-platform os/arch本地構建目標平臺默認linux/宿主機架構--local-node-image tag本地構建節(jié)點的鏡像標簽默認cre-node:local。在默認拓撲上運行 E2E 測試環(huán)境起來后切到測試目錄執(zhí)行測試。測試命令必須在system-tests/tests下運行這一目錄本身是一個獨立的 Go module見 system-tests/tests/go.mod。常規(guī) CRE 冒煙套件cd system-tests/tests go test ./smoke/cre -timeout 20m -run ^Test_CRE_僅 V2 冒煙套件cd system-tests/tests go test ./smoke/cre -timeout 15m -run ^Test_CRE_V2回歸測試cd system-tests/tests go test ./regression/cre -timeout 20m -run ^Test_CRE_smoke 與 regression 的劃分規(guī)則SKILL.md 給出的經驗法則與源碼注釋完全一致smoke面向 happy path 與 sanity 覆蓋regression面向邊界條件與負向場景。這一點在測試入口文件 cre_suite_test.go 的注釋中寫得很明確//////////// SMOKE TESTS ///////////// // target happy path and sanity checks // all other tests (e.g. edge cases, negative conditions) // should go to a regression package /////////////////////////////////////測試與環(huán)境的銜接機制你可能好奇為什么先啟動 Local CRE 再跑測試就能對上這依賴system-tests/tests/test-helpers/before_suite.go中的 helper 邏輯before_suite.go如果CTF_CONFIGS為空helper 會把它設置為請求的配置如果本地 CRE 狀態(tài)文件Local CRE state file不存在helper 會自動執(zhí)行go run . env start把環(huán)境拉起來環(huán)境創(chuàng)建完成后CTF_CONFIGS會被切換為指向本地 CRE 狀態(tài)文件而不是原始拓撲 TOML從而讓測試使用已部署的環(huán)境。因此兩種工作方式都成立手動先起環(huán)境再跑測試或直接讓 helper 幫你引導環(huán)境。運行特定測試或桶用窄正則調試單個場景當你在排查單個場景或某個桶時使用收窄的正則表達式并配合-count1防止測試緩存帶來的假結果cd system-tests/tests go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -v按場景子路徑過濾V2 套件內部按場景組織子測試可以用/繼續(xù)下鉆cd system-tests/tests go test ./smoke/cre -timeout 20m -run Test_CRE_V2_Suite_Bucket_B/.*/Vault -count1 -vcd system-tests/tests go test ./regression/cre -timeout 20m -run ^Test_CRE_V2_Consensus_Regression$ -count1 -vSKILL.md 強調重跑易 flaky 或帶狀態(tài)stateful的 CRE 場景時務必加-count1跳過 Go 測試緩存確保從頭執(zhí)行。桶Bucket結構與場景分配較大的 CRE 冒煙套件按運行時均衡拆分為多個桶而不是一個巨型測試入口。舊的 V2 套件拆分為Test_CRE_V2_Suite_Bucket_ATest_CRE_V2_Suite_Bucket_BTest_CRE_V2_Suite_Bucket_C入口定義在 cre_suite_test.go每個入口都會先校驗桶注冊表再執(zhí)行場景。桶到場景的分配定義在 system-tests/tests/smoke/cre/config/bucketing.go桶包含場景suite-bucket-aProofOfReserve、HTTPTriggerAction、DONTime、Consensussuite-bucket-bVaultDONsuite-bucket-cCronChipIngressStack、HTTPActionCRUD、HTTPActionMultiGateway除非TOPOLOGY_NAME含multi-gateway否則跳過suiteBucketRegistry是舊 V2 套件場景分配桶的唯一登記處新增場景時應在此添加并通過 CI 實測時間重新均衡各桶運行時bucketing.go 的注釋給出了這一維護流程。EVM 讀取套件還有一套獨立的桶注冊表位于 system-tests/tests/smoke/cre/evm/evmread/config/bucketing.go對應入口Test_CRE_V2_EVM_Read_HeavyCallsTest_CRE_V2_EVM_Read_StateQueriesTest_CRE_V2_EVM_Read_TxArtifacts使用桶化入口的意義在于更短的本地反饋回路、更穩(wěn)定的 CI 運行時長以及在套件增長時可控地再平衡場景運行時。本地調試的 VS Code 配置docs/local-cre/system-tests/running-tests.md 提供了一個可直接套用的 VS Code launch 配置模板{ name: Launch CRE V2 Bucket A, type: go, request: launch, mode: test, program: ${workspaceFolder}/system-tests/tests/smoke/cre, args: [-test.run, ^Test_CRE_V2_Suite_Bucket_A$] }配合 debug 日志跑一個窄測試的常見形態(tài)是CTF_LOG_LEVELdebug \ go test ./system-tests/tests/smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_A$CTF_LOG_LEVELdebug會讓框架在 setup 與測試執(zhí)行階段輸出更詳細的日志而窄化的-run保證仍走與完整套件相同的拓撲與工作流 setup。使用特定拓撲當測試需要特定的 DON 布局、鏈或功能配置時使用非默認拓撲。流程停舊環(huán)境 → 指定拓撲啟動 → 跑目標測試# 1. 停止現(xiàn)有環(huán)境 cd core/scripts/cre/environment go run . env stop -a # 2. 用 CTF_CONFIGS 指定拓撲文件啟動 cd core/scripts/cre/environment CTF_CONFIGS./configs/workflow-gateway-capabilities-don.toml go run . env start # 3. 運行目標測試TOPOLOGY_NAME 可選 cd system-tests/tests TOPOLOGY_NAMEworkflow-gateway-capabilities \ go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -vTOPOLOGY_NAME的作用TOPOLOGY_NAME是可選但很有用的環(huán)境變量。為什么有用因為大量 CRE 套件測試會把拓撲名包含進子測試名、桶標簽與日志輸出讓結果始終與所測拓撲掛鉤。實現(xiàn)上套件入口在 cre_suite_test.go 直接讀取該變量var ( parallelEnabled t_helpers.ParallelEnabled() // topology is used in test names topology os.Getenv(TOPOLOGY_NAME) )典型例子多網關 HTTP action 路由場景需要啟動configs/workflow-gateway-capabilities-multi-gateway-don.toml然后執(zhí)行TOPOLOGY_NAMEworkflow-gateway-capabilities-multi-gateway \ go test ./system-tests/tests/smoke/cre -timeout 20m -run ^Test_CRE_V2_HTTP_Action_Multi_Gateway$測試助手的拓撲銜接細節(jié)docs/local-cre/system-tests/running-tests.md 匯總了冒煙套件使用的核心環(huán)境變量CTF_CONFIGS啟動前指向拓撲 TOML啟動后被 helper 自動切換為生成的 Local CRE 狀態(tài)文件本地運行由before_suite.go完成切換TOPOLOGY_NAME進入測試名、桶標簽與日志輸出CTF_LOG_LEVELdebug啟用更詳細的框架日志CTF_JD_IMAGE固定 Job Distributor 鏡像避免默認本地鏡像選擇CTF_CHAINLINK_IMAGE固定 Chainlink 節(jié)點鏡像system-tests/lib/cre/environment/dons.go 在選擇節(jié)點鏡像時直接檢查該變量。并行執(zhí)行可選并行測試是顯式開啟的設置環(huán)境變量即可CRE_TEST_PARALLEL_ENABLED1注意冒煙套件并不會盲目地對所有用例開t.Parallel()——runner 在cre_suite_test.go中只對確定可以安全共存的場景啟用并行。創(chuàng)建自定義拓撲當你想覆蓋以下內容時就需要創(chuàng)建自定義拓撲limitsfeature flagscapability 配置DON 組成額外的數據源user_config_overrides。工作流從core/scripts/cre/environment/configs/里挑一個最接近現(xiàn)有需求的拓撲復制為同目錄下的新文件只改場景需要的字段用CTF_CONFIGS新拓撲啟動本地 CRE先只跑相關測試。示例cd core/scripts/cre/environment/configs cp workflow-gateway-capabilities-don.toml workflow-gateway-capabilities-don-my-override.toml然后啟動并測試cd ../ CTF_CONFIGS./configs/workflow-gateway-capabilities-don-my-override.toml go run . env startcd ../../../system-tests/tests TOPOLOGY_NAMEworkflow-gateway-capabilities-my-override \ go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -v默認拓撲長什么樣理解默認拓撲是定制的基礎。workflow-gateway-capabilities-don.tomlconfigs/workflow-gateway-capabilities-don.toml是一個 multi-don 拓撲包含 3 個 nodesetworkflow4 個節(jié)點don_types [workflow]capabilities 含cron、http-action、http-trigger、consensus、don-time、evm-1337同時連接 1337/2337 兩條 anvil 鏈注釋解釋即使不用 2337 上的 capabilitybootstrap 節(jié)點上仍要創(chuàng)建 capability DON 的 bootstrap jobcapabilities4 個節(jié)點don_types [capabilities]exposes_remote_capabilities truecapabilities 含vault、evm-2337連接 1337 是為了用鏈上節(jié)點地址在 gateway 配置中標識節(jié)點這是 vault 與 gateway 型 HTTP capability 的要求bootstrap-gateway1 個節(jié)點don_types [bootstrap, gateway]override_mode each通過custom_ports [5002:5002,15002:15002]暴露 web API capabilities 端口5002與 vault 端口15002。其他公共段包括[chip_router]、兩條[[blockchains]]anvil 1337/2337、[jd]Job Distributor 鏡像與 CSA 加密密鑰、[fake]/[fake_http]mock 服務端口、[infra]docker 或 kubernetes。倉庫現(xiàn)有拓撲的全量清單可參考 core/scripts/cre/environment/docs/TOPOLOGIES.md該文件由go run . topology generate自動生成涵蓋workflow-don-solana.tomlmulti-don3 DONworkflow-gateway-capabilities-multi-gateway-don.tomlmulti-don4 DONworkflow-gateway-don-aptos.tomlsingle-don2 DONworkflow-gateway-don-cache-test.toml/workflow-gateway-don-cache-soak-test.tomlworkflow-gateway-don-grpc-source.tomlworkflow-gateway-don.tomlsingle-don2 DONworkflow-gateway-sharded-5-dons.tomlsharded7 DONworkflow-gateway-sharded-don.tomlsharded3 DON快速查看清單可運行go run . topology list。覆蓋指南制作自定義拓撲時的紀律SKILL.md 原文要點保持 diff 小而目的明確優(yōu)先復制最近似的拓撲而不是從零新建使用能表明改動內容的描述性文件名除非測試需要不要改動無關的鏡像、鏈或 capability如果拓撲只用于一次性本地檢查保留在本地避免加進 CI。典型的覆蓋點包括nodesets.capability_configscapability 配置覆蓋nodesets.user_config_overrides節(jié)點用戶配置覆蓋CRE feature flags額外的 mock 或支持服務端點。capability_configs 的完整覆蓋語義倉庫提供了一個專門講解覆蓋寫法的示例拓撲 configs/examples/workflow-don-overrides.toml其中對capability_configs的關鍵語義寫得很清楚覆蓋某個 capability 配置時必須提供該 capability 的全部值——不支持部分覆蓋。如果你指定了某個 key整個CapabilityConfig會原樣使用不會與默認值合并默認值只對完全沒有配置的 capability 生效。示例鏈級 EVM 覆蓋LogTriggerPollInterval以納秒為單位[nodesets.capability_configs.evm-1337.values] LogTriggerPollInterval 2500000000 # 2.5s in nanoseconds # 其他 capability 同樣可覆蓋例如 # [nodesets.capability_configs.http-action] # binary_name http_action # [nodesets.capability_configs.http-action.values] # IncomingGlobalBurst 20user_config_overrides 的邊界與寫法同一示例還演示了user_config_overrides的用法并給出一個重要的實現(xiàn)約束[Telemetry]、[Billing]、[Metering]是框架托管的段會被框架拒絕validateUserConfigOverrides位于system-tests/lib因為框架會自己生成這些配置把遙測指向 chip-router 以便下游訂閱者如 CI test sink看到全部事件。要啟用 metering應設置 nodeset 的enable_metering true。[[nodesets.node_specs]] roles [plugin] # override_mode all 時DON 內所有節(jié)點都是 plugin 角色 [nodesets.node_specs.node] image chainlink-tmp:latest user_config_overrides [Log] Level debug JSONConsole true # 刪掉這段可以讓工作流從遠程源下載 [CRE.WorkflowFetcher] URL file:///home/chainlink/workflows 重啟與清理干凈重啟當改動拓撲或底層配置時優(yōu)先完整 stop/start不要假設運行中的環(huán)境會自動收斂cd core/scripts/cre/environment go run . env stop -a CTF_CONFIGS./configs/topology.toml go run . env start這也是 SKILL.md 故障排查的第一條如果測試意外使用了錯誤的拓撲停止 Local CRE 并按預期的CTF_CONFIGS重啟。用完后清理cd core/scripts/cre/environment go run . env stop -a徹底重置當保存的狀態(tài)或緩存產物看起來不一致時使用 purgego run . env state purgestate子命令組定義在 environment.go包含list列出環(huán)境中所有狀態(tài)文件與purge清空所有狀態(tài)與緩存文件。Local CRE 把環(huán)境狀態(tài)持久化到倉庫本地的狀態(tài)文件中這正是冒煙測試 helper 能檢測到已存在環(huán)境、避免重復創(chuàng)建的原因詳見 docs/local-cre/environment/index.md。需要完全重置時先 purge 狀態(tài)再重新 setup/start。故障排除SKILL.md 的四條速查測試意外使用了錯誤拓撲→ 停止 Local CRE按預期的CTF_CONFIGS重啟套件似乎在復用陳舊狀態(tài)→ 用-count1重跑測試依賴日志、追蹤或面板→ 執(zhí)行go run . obs up拓撲相關的失敗看似與測試無關→ 先確認環(huán)境確實是以預期拓撲啟動的。測試邏輯尚未執(zhí)行就失敗的清單docs/local-cre/system-tests/running-tests.md 給出了測試還沒跑到測試邏輯就失敗時的五步檢查確認CTF_CONFIGS確認 Local CRE 狀態(tài)文件有效確認所需鏡像存在重跑go run . env setup用 debug 日志重跑。環(huán)境啟動階段的高頻故障docs/local-cre/environment/index.md 歸納了環(huán)境側最常見的四類失敗Chainlink 節(jié)點數據庫遷移失敗Docker 鏡像找不到Docker 無法下載所需公共鏡像gh缺失或未認證構建需要私有插件訪問的鏡像時必需。對應的處理順序重跑go run . env setup→ 確認鏡像訪問與認證 → 狀態(tài)陳舊則 purge 狀態(tài) → 需要更多信號則帶 observability 或 Chip Ingress 棧重啟。超時經驗實踐中的超時經驗來自 docs/local-cre/system-tests/running-tests.md從源碼構建鏡像時給約20 分鐘的預算使用預構建鏡像時運行時長會短得多。深入參考本文基于的 SKILL 文檔還推薦了以下倉庫內資料供深入閱讀docs/local-cre/index.mdLocal CRE 文檔總覽與導航docs/local-cre/system-tests/index.mdCRE 系統(tǒng)測試的結構、smoke/regression 劃分與 helper 銜接機制docs/local-cre/system-tests/running-tests.md本地、Kubernetes 與 CI 視角下的運行細節(jié)、環(huán)境變量與桶化選擇docs/local-cre/getting-started/index.md從干凈 checkout 到跑起第一個環(huán)境的最短路徑docs/local-cre/environment/index.md環(huán)境生命周期命令、env start全部 flag 與 Chip 端口布局core/scripts/cre/environment環(huán)境 CLI 源碼main.go命令注冊、environment/生命周期實現(xiàn)、configs/拓撲目錄system-tests/tests/smoke/cre冒煙套件源碼cre_suite_test.go桶入口、config/bucketing.go桶注冊表?！久赓M下載鏈接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation項目地址: https://gitcode.com/GitHub_Trending/ch/chainlink創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 Chainlink 本地 CRE E2E 實戰(zhàn)指南：環(huán)境生命周期、冒煙/回歸測試與自定義拓撲
Chainlink 本地 CRE E2E 實戰(zhàn)指南環(huán)境生命周期、冒煙/回歸測試與自定義拓撲【免費下載鏈接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation項目地址: https://gitcode.com/GitHub_Trending/ch/chainlink本文面向需要在chainlink倉庫中本地開發(fā)、調試 CREChainlink Runtime Environment鏈上/鏈下工作流運行時的開發(fā)者和測試工程師系統(tǒng)講解如何在本地拉起完整的 CRE 環(huán)境、運行 CRE 冒煙/回歸端到端測試以及通過自定義拓撲覆蓋 limits、feature flags、capability 配置與user_config_overrides的完整方法。讀完本文你將掌握從env stop到env start的完整環(huán)境生命周期操作、默認拓撲下的測試執(zhí)行套路以及基于CTF_CONFIGS 拓撲 TOML 靈活定制測試場景的實戰(zhàn)技能。本文的核心依據是倉庫內 Agent Skill 文檔 docs/local-cre/agent-skills/local-cre-e2e/SKILL.md并輔以 Local CRE 環(huán)境 CLI 與 CRE 冒煙測試套件 的源碼佐證。適用范圍與基本假設這個 Skill 解決什么問題local-cre-e2e是一個面向 Agent 與開發(fā)者的操作技能說明適用于以下場景啟動、停止或重啟本地 CRE 環(huán)境在默認拓撲上運行 CRE 冒煙smoke或回歸regression端到端測試針對特定拓撲運行測試創(chuàng)建自定義拓撲以覆蓋 limits、flags、capability 配置或user_config_overrides。需要特別注意的是它面向的是Local CRE 系統(tǒng)級測試工作流不適用于普通單元測試。運行前提假設根據 SKILL.md使用該工作流需滿足四個前提倉庫根目錄是chainlink的檢出目錄即當前倉庫根本地 CRE 命令統(tǒng)一在core/scripts/cre/environment目錄下執(zhí)行CRE E2E 測試命令統(tǒng)一在system-tests/tests目錄下執(zhí)行除非明確知道 harness 支持隔離否則同一時間只應有一個活動的本地 CRE 環(huán)境——這是避免狀態(tài)串擾的關鍵紀律。從源碼看CLI 入口位于 core/scripts/cre/environment/main.go它把env、topology、examples、bs、obs五組子命令掛到根命令root.RootCmd上因此所有環(huán)境操作都通過go run . command [subcommand]的統(tǒng)一形態(tài)調用。默認工作流從清理到啟動一次本地 CRE第一步停止可能存在的舊環(huán)境每次開始前先徹底停止可能殘留的本地 CRE 環(huán)境避免新環(huán)境與舊狀態(tài)的端口、容器、狀態(tài)文件沖突cd core/scripts/cre/environment go run . env stop -a-a--all會連同所有額外服務一起停止。對應源碼見 environment.go 中stop子命令的定義其提示信息明確寫道All extra services: stop withgo run . env stop --all。第二步一次性準備環(huán)境如果環(huán)境尚未準備過或需要重新拉取/構建依賴鏡像先執(zhí)行一次設置cd core/scripts/cre/environment go run . env setupenv setup由configs/setup.toml驅動負責確保 Job Distributor、Chip Router、Chip Ingress、Chip Config 等托管鏡像就緒。它也可以顯式指定配置并跳過交互提示go run . env setup --config configs/setup.toml --no-prompt如果需要重建或重新拉取全部前置依賴env setup支持--purge需要計費billing資產時可加--with-billing詳見 docs/local-cre/getting-started/index.md。提示env setup并非每次都要跑。鏡像已經就位、只改拓撲 TOML 的情況下直接env start即可。SKILL.md 強調它是環(huán)境尚未準備時的一次性步驟。第三步啟動默認拓撲cd core/scripts/cre/environment go run . env startenv start默認讀取CTF_CONFIGS指向的拓撲 TOML未設置時使用默認拓撲workflow-gateway-capabilities-don.toml。對應源碼見 environment.go其中還包含對 Job Distributor 鏡像的存在性檢查environment.go若鏡像缺失會提示先執(zhí)行go run . env setup?？焖偕鲜謺r也可以一步到位使用--auto-setupgo run . env start --auto-setup第四步可選啟動可觀測性組件go run . obs up當你需要日志、追蹤或面板來調試工作流事件時用obs up拉起 observability 輔助棧。SKILL.md 特別指出當測試依賴真實 ChIP Ingress ?；蚰阆胗肦ed Panda Console調試工作流事件時在env start上加--with-chip-ingress-stack--with-beholder已廢棄deprecated等價行為請改用--with-chip-ingress-stack。為什么默認冒煙流程不建議開--with-chip-ingress-stackdocs/local-cre/system-tests/running-tests.md 給出了實現(xiàn)層面的原因大多數 CRE 冒煙測試會在默認 gRPC 端口50051上啟動 ChIP 測試 sinktest sink而 Chip Ingress 棧的 ChIP ingress 也綁定同一端口。兩者搶同一端口會導致測試 sink 啟動失敗。因此僅在以下情況才啟用該棧你在跑 Chip Ingress 棧專屬的覆蓋場景你需要用它做調試你通過--grpc-port給它換一個端口把默認50051留給測試 sink。Chip 相關組件的默認端口布局來自 docs/local-cre/environment/index.md50050Chip Router admin API50051Chip Router ingress gRPC50052chip-config50053真實 ChIP / Chip Ingress 棧 gRPC。補充本地源碼構建模式在默認拓撲基礎上如果你正在開發(fā) node 或某個 capabilitydocs/local-cre/environment/index.md 還提供了兩個高頻擴展 flag# 節(jié)點 全部 capability 都用本地工作樹構建含 observability go run . env start --with-observability --local-node --local-capabilities all # 節(jié)點用固定鏡像僅 cron evm 用本地構建覆蓋 go run . env start --local-capabilities cron,evm--local-node在宿主機交叉編譯本地 checkout 的 Chainlink 節(jié)點并烘焙進最小鏡像覆蓋拓撲中的docker_ctx/image--local-capabilities names|all從本地源碼構建指定 CRE capability 并注入節(jié)點未列出的 capability 保留鏡像內版本--capabilities-path dir本地 capabilities 倉庫位置默認$CRE_CAPABILITIES_PATH否則為~/go/src/github.com/smartcontractkit/capabilities--local-build-platform os/arch本地構建目標平臺默認linux/宿主機架構--local-node-image tag本地構建節(jié)點的鏡像標簽默認cre-node:local。在默認拓撲上運行 E2E 測試環(huán)境起來后切到測試目錄執(zhí)行測試。測試命令必須在system-tests/tests下運行這一目錄本身是一個獨立的 Go module見 system-tests/tests/go.mod。常規(guī) CRE 冒煙套件cd system-tests/tests go test ./smoke/cre -timeout 20m -run ^Test_CRE_僅 V2 冒煙套件cd system-tests/tests go test ./smoke/cre -timeout 15m -run ^Test_CRE_V2回歸測試cd system-tests/tests go test ./regression/cre -timeout 20m -run ^Test_CRE_smoke 與 regression 的劃分規(guī)則SKILL.md 給出的經驗法則與源碼注釋完全一致smoke面向 happy path 與 sanity 覆蓋regression面向邊界條件與負向場景。這一點在測試入口文件 cre_suite_test.go 的注釋中寫得很明確//////////// SMOKE TESTS ///////////// // target happy path and sanity checks // all other tests (e.g. edge cases, negative conditions) // should go to a regression package /////////////////////////////////////測試與環(huán)境的銜接機制你可能好奇為什么先啟動 Local CRE 再跑測試就能對上這依賴system-tests/tests/test-helpers/before_suite.go中的 helper 邏輯before_suite.go如果CTF_CONFIGS為空helper 會把它設置為請求的配置如果本地 CRE 狀態(tài)文件Local CRE state file不存在helper 會自動執(zhí)行go run . env start把環(huán)境拉起來環(huán)境創(chuàng)建完成后CTF_CONFIGS會被切換為指向本地 CRE 狀態(tài)文件而不是原始拓撲 TOML從而讓測試使用已部署的環(huán)境。因此兩種工作方式都成立手動先起環(huán)境再跑測試或直接讓 helper 幫你引導環(huán)境。運行特定測試或桶用窄正則調試單個場景當你在排查單個場景或某個桶時使用收窄的正則表達式并配合-count1防止測試緩存帶來的假結果cd system-tests/tests go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -v按場景子路徑過濾V2 套件內部按場景組織子測試可以用/繼續(xù)下鉆cd system-tests/tests go test ./smoke/cre -timeout 20m -run Test_CRE_V2_Suite_Bucket_B/.*/Vault -count1 -vcd system-tests/tests go test ./regression/cre -timeout 20m -run ^Test_CRE_V2_Consensus_Regression$ -count1 -vSKILL.md 強調重跑易 flaky 或帶狀態(tài)stateful的 CRE 場景時務必加-count1跳過 Go 測試緩存確保從頭執(zhí)行。桶Bucket結構與場景分配較大的 CRE 冒煙套件按運行時均衡拆分為多個桶而不是一個巨型測試入口。舊的 V2 套件拆分為Test_CRE_V2_Suite_Bucket_ATest_CRE_V2_Suite_Bucket_BTest_CRE_V2_Suite_Bucket_C入口定義在 cre_suite_test.go每個入口都會先校驗桶注冊表再執(zhí)行場景。桶到場景的分配定義在 system-tests/tests/smoke/cre/config/bucketing.go桶包含場景suite-bucket-aProofOfReserve、HTTPTriggerAction、DONTime、Consensussuite-bucket-bVaultDONsuite-bucket-cCronChipIngressStack、HTTPActionCRUD、HTTPActionMultiGateway除非TOPOLOGY_NAME含multi-gateway否則跳過suiteBucketRegistry是舊 V2 套件場景分配桶的唯一登記處新增場景時應在此添加并通過 CI 實測時間重新均衡各桶運行時bucketing.go 的注釋給出了這一維護流程。EVM 讀取套件還有一套獨立的桶注冊表位于 system-tests/tests/smoke/cre/evm/evmread/config/bucketing.go對應入口Test_CRE_V2_EVM_Read_HeavyCallsTest_CRE_V2_EVM_Read_StateQueriesTest_CRE_V2_EVM_Read_TxArtifacts使用桶化入口的意義在于更短的本地反饋回路、更穩(wěn)定的 CI 運行時長以及在套件增長時可控地再平衡場景運行時。本地調試的 VS Code 配置docs/local-cre/system-tests/running-tests.md 提供了一個可直接套用的 VS Code launch 配置模板{ name: Launch CRE V2 Bucket A, type: go, request: launch, mode: test, program: ${workspaceFolder}/system-tests/tests/smoke/cre, args: [-test.run, ^Test_CRE_V2_Suite_Bucket_A$] }配合 debug 日志跑一個窄測試的常見形態(tài)是CTF_LOG_LEVELdebug \ go test ./system-tests/tests/smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_A$CTF_LOG_LEVELdebug會讓框架在 setup 與測試執(zhí)行階段輸出更詳細的日志而窄化的-run保證仍走與完整套件相同的拓撲與工作流 setup。使用特定拓撲當測試需要特定的 DON 布局、鏈或功能配置時使用非默認拓撲。流程停舊環(huán)境 → 指定拓撲啟動 → 跑目標測試# 1. 停止現(xiàn)有環(huán)境 cd core/scripts/cre/environment go run . env stop -a # 2. 用 CTF_CONFIGS 指定拓撲文件啟動 cd core/scripts/cre/environment CTF_CONFIGS./configs/workflow-gateway-capabilities-don.toml go run . env start # 3. 運行目標測試TOPOLOGY_NAME 可選 cd system-tests/tests TOPOLOGY_NAMEworkflow-gateway-capabilities \ go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -vTOPOLOGY_NAME的作用TOPOLOGY_NAME是可選但很有用的環(huán)境變量。為什么有用因為大量 CRE 套件測試會把拓撲名包含進子測試名、桶標簽與日志輸出讓結果始終與所測拓撲掛鉤。實現(xiàn)上套件入口在 cre_suite_test.go 直接讀取該變量var ( parallelEnabled t_helpers.ParallelEnabled() // topology is used in test names topology os.Getenv(TOPOLOGY_NAME) )典型例子多網關 HTTP action 路由場景需要啟動configs/workflow-gateway-capabilities-multi-gateway-don.toml然后執(zhí)行TOPOLOGY_NAMEworkflow-gateway-capabilities-multi-gateway \ go test ./system-tests/tests/smoke/cre -timeout 20m -run ^Test_CRE_V2_HTTP_Action_Multi_Gateway$測試助手的拓撲銜接細節(jié)docs/local-cre/system-tests/running-tests.md 匯總了冒煙套件使用的核心環(huán)境變量CTF_CONFIGS啟動前指向拓撲 TOML啟動后被 helper 自動切換為生成的 Local CRE 狀態(tài)文件本地運行由before_suite.go完成切換TOPOLOGY_NAME進入測試名、桶標簽與日志輸出CTF_LOG_LEVELdebug啟用更詳細的框架日志CTF_JD_IMAGE固定 Job Distributor 鏡像避免默認本地鏡像選擇CTF_CHAINLINK_IMAGE固定 Chainlink 節(jié)點鏡像system-tests/lib/cre/environment/dons.go 在選擇節(jié)點鏡像時直接檢查該變量。并行執(zhí)行可選并行測試是顯式開啟的設置環(huán)境變量即可CRE_TEST_PARALLEL_ENABLED1注意冒煙套件并不會盲目地對所有用例開t.Parallel()——runner 在cre_suite_test.go中只對確定可以安全共存的場景啟用并行。創(chuàng)建自定義拓撲當你想覆蓋以下內容時就需要創(chuàng)建自定義拓撲limitsfeature flagscapability 配置DON 組成額外的數據源user_config_overrides。工作流從core/scripts/cre/environment/configs/里挑一個最接近現(xiàn)有需求的拓撲復制為同目錄下的新文件只改場景需要的字段用CTF_CONFIGS新拓撲啟動本地 CRE先只跑相關測試。示例cd core/scripts/cre/environment/configs cp workflow-gateway-capabilities-don.toml workflow-gateway-capabilities-don-my-override.toml然后啟動并測試cd ../ CTF_CONFIGS./configs/workflow-gateway-capabilities-don-my-override.toml go run . env startcd ../../../system-tests/tests TOPOLOGY_NAMEworkflow-gateway-capabilities-my-override \ go test ./smoke/cre -timeout 20m -run ^Test_CRE_V2_Suite_Bucket_B$ -count1 -v默認拓撲長什么樣理解默認拓撲是定制的基礎。workflow-gateway-capabilities-don.tomlconfigs/workflow-gateway-capabilities-don.toml是一個 multi-don 拓撲包含 3 個 nodesetworkflow4 個節(jié)點don_types [workflow]capabilities 含cron、http-action、http-trigger、consensus、don-time、evm-1337同時連接 1337/2337 兩條 anvil 鏈注釋解釋即使不用 2337 上的 capabilitybootstrap 節(jié)點上仍要創(chuàng)建 capability DON 的 bootstrap jobcapabilities4 個節(jié)點don_types [capabilities]exposes_remote_capabilities truecapabilities 含vault、evm-2337連接 1337 是為了用鏈上節(jié)點地址在 gateway 配置中標識節(jié)點這是 vault 與 gateway 型 HTTP capability 的要求bootstrap-gateway1 個節(jié)點don_types [bootstrap, gateway]override_mode each通過custom_ports [5002:5002,15002:15002]暴露 web API capabilities 端口5002與 vault 端口15002。其他公共段包括[chip_router]、兩條[[blockchains]]anvil 1337/2337、[jd]Job Distributor 鏡像與 CSA 加密密鑰、[fake]/[fake_http]mock 服務端口、[infra]docker 或 kubernetes。倉庫現(xiàn)有拓撲的全量清單可參考 core/scripts/cre/environment/docs/TOPOLOGIES.md該文件由go run . topology generate自動生成涵蓋workflow-don-solana.tomlmulti-don3 DONworkflow-gateway-capabilities-multi-gateway-don.tomlmulti-don4 DONworkflow-gateway-don-aptos.tomlsingle-don2 DONworkflow-gateway-don-cache-test.toml/workflow-gateway-don-cache-soak-test.tomlworkflow-gateway-don-grpc-source.tomlworkflow-gateway-don.tomlsingle-don2 DONworkflow-gateway-sharded-5-dons.tomlsharded7 DONworkflow-gateway-sharded-don.tomlsharded3 DON快速查看清單可運行go run . topology list。覆蓋指南制作自定義拓撲時的紀律SKILL.md 原文要點保持 diff 小而目的明確優(yōu)先復制最近似的拓撲而不是從零新建使用能表明改動內容的描述性文件名除非測試需要不要改動無關的鏡像、鏈或 capability如果拓撲只用于一次性本地檢查保留在本地避免加進 CI。典型的覆蓋點包括nodesets.capability_configscapability 配置覆蓋nodesets.user_config_overrides節(jié)點用戶配置覆蓋CRE feature flags額外的 mock 或支持服務端點。capability_configs 的完整覆蓋語義倉庫提供了一個專門講解覆蓋寫法的示例拓撲 configs/examples/workflow-don-overrides.toml其中對capability_configs的關鍵語義寫得很清楚覆蓋某個 capability 配置時必須提供該 capability 的全部值——不支持部分覆蓋。如果你指定了某個 key整個CapabilityConfig會原樣使用不會與默認值合并默認值只對完全沒有配置的 capability 生效。示例鏈級 EVM 覆蓋LogTriggerPollInterval以納秒為單位[nodesets.capability_configs.evm-1337.values] LogTriggerPollInterval 2500000000 # 2.5s in nanoseconds # 其他 capability 同樣可覆蓋例如 # [nodesets.capability_configs.http-action] # binary_name http_action # [nodesets.capability_configs.http-action.values] # IncomingGlobalBurst 20user_config_overrides 的邊界與寫法同一示例還演示了user_config_overrides的用法并給出一個重要的實現(xiàn)約束[Telemetry]、[Billing]、[Metering]是框架托管的段會被框架拒絕validateUserConfigOverrides位于system-tests/lib因為框架會自己生成這些配置把遙測指向 chip-router 以便下游訂閱者如 CI test sink看到全部事件。要啟用 metering應設置 nodeset 的enable_metering true。[[nodesets.node_specs]] roles [plugin] # override_mode all 時DON 內所有節(jié)點都是 plugin 角色 [nodesets.node_specs.node] image chainlink-tmp:latest user_config_overrides [Log] Level debug JSONConsole true # 刪掉這段可以讓工作流從遠程源下載 [CRE.WorkflowFetcher] URL file:///home/chainlink/workflows 重啟與清理干凈重啟當改動拓撲或底層配置時優(yōu)先完整 stop/start不要假設運行中的環(huán)境會自動收斂cd core/scripts/cre/environment go run . env stop -a CTF_CONFIGS./configs/topology.toml go run . env start這也是 SKILL.md 故障排查的第一條如果測試意外使用了錯誤的拓撲停止 Local CRE 并按預期的CTF_CONFIGS重啟。用完后清理cd core/scripts/cre/environment go run . env stop -a徹底重置當保存的狀態(tài)或緩存產物看起來不一致時使用 purgego run . env state purgestate子命令組定義在 environment.go包含list列出環(huán)境中所有狀態(tài)文件與purge清空所有狀態(tài)與緩存文件。Local CRE 把環(huán)境狀態(tài)持久化到倉庫本地的狀態(tài)文件中這正是冒煙測試 helper 能檢測到已存在環(huán)境、避免重復創(chuàng)建的原因詳見 docs/local-cre/environment/index.md。需要完全重置時先 purge 狀態(tài)再重新 setup/start。故障排除SKILL.md 的四條速查測試意外使用了錯誤拓撲→ 停止 Local CRE按預期的CTF_CONFIGS重啟套件似乎在復用陳舊狀態(tài)→ 用-count1重跑測試依賴日志、追蹤或面板→ 執(zhí)行go run . obs up拓撲相關的失敗看似與測試無關→ 先確認環(huán)境確實是以預期拓撲啟動的。測試邏輯尚未執(zhí)行就失敗的清單docs/local-cre/system-tests/running-tests.md 給出了測試還沒跑到測試邏輯就失敗時的五步檢查確認CTF_CONFIGS確認 Local CRE 狀態(tài)文件有效確認所需鏡像存在重跑go run . env setup用 debug 日志重跑。環(huán)境啟動階段的高頻故障docs/local-cre/environment/index.md 歸納了環(huán)境側最常見的四類失敗Chainlink 節(jié)點數據庫遷移失敗Docker 鏡像找不到Docker 無法下載所需公共鏡像gh缺失或未認證構建需要私有插件訪問的鏡像時必需。對應的處理順序重跑go run . env setup→ 確認鏡像訪問與認證 → 狀態(tài)陳舊則 purge 狀態(tài) → 需要更多信號則帶 observability 或 Chip Ingress 棧重啟。超時經驗實踐中的超時經驗來自 docs/local-cre/system-tests/running-tests.md從源碼構建鏡像時給約20 分鐘的預算使用預構建鏡像時運行時長會短得多。深入參考本文基于的 SKILL 文檔還推薦了以下倉庫內資料供深入閱讀docs/local-cre/index.mdLocal CRE 文檔總覽與導航docs/local-cre/system-tests/index.mdCRE 系統(tǒng)測試的結構、smoke/regression 劃分與 helper 銜接機制docs/local-cre/system-tests/running-tests.md本地、Kubernetes 與 CI 視角下的運行細節(jié)、環(huán)境變量與桶化選擇docs/local-cre/getting-started/index.md從干凈 checkout 到跑起第一個環(huán)境的最短路徑docs/local-cre/environment/index.md環(huán)境生命周期命令、env start全部 flag 與 Chip 端口布局core/scripts/cre/environment環(huán)境 CLI 源碼main.go命令注冊、environment/生命周期實現(xiàn)、configs/拓撲目錄system-tests/tests/smoke/cre冒煙套件源碼cre_suite_test.go桶入口、config/bucketing.go桶注冊表?！久赓M下載鏈接】chainlinknode of the decentralized oracle network, bridging on and off-chain computation項目地址: https://gitcode.com/GitHub_Trending/ch/chainlink創(chuàng)作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考