Refactor CI workflows with new release and sync test configurations

[pablomendezroyo]

"Replace the main CI workflow with a more structured release workflow and introduce a sync test workflow for execution clients, enhancing the overall CI process.

[github-actions]

✅ SYNC TEST REPORT - PASSED

This CI runs on a real DAppNode using the same RPC calls a user would make to configure a staker setup: execution client, consensus client, web3signer, MEV-boost, and relays. The self-hosted runner is pre-loaded with synced (or near-synced) execution client volumes, enabling fast sync and attestation tests with any client combination. Consensus clients use checkpoint sync, so no pre-synced volume is required.

Sync Test: Verifies that both execution and consensus clients reach a synced state. This test ensures the staker configuration is valid and clients can synchronize with the network.

📦 Clients Used

Component	DNP Name	DNP Version
Execution	hoodi-geth.dnp.dappnode.eth	0.1.4
Consensus	lodestar-hoodi.dnp.dappnode.eth	0.1.7
Web3Signer	web3signer-hoodi.dnp.dappnode.eth	0.1.3
MEV Boost	mev-boost-hoodi.dnp.dappnode.eth	0.1.1
Network	hoodi

🔖 Version Tracking

Execution Client Versions

Stage	Version
Before Install	Geth/v1.16.8-stable-abeb78c6/linux-amd64/go1.24.11
After Install	Geth/v1.16.8-stable-abeb78c6/linux-amd64/go1.24.11

Consensus Client Versions

Stage	Version
Before Install	Lodestar/v1.39.1/bc422a0
After Install	Lodestar/v1.39.1/bc422a0

⏱️ Timing Measurements

Environment Setup

Operation	Duration	Status
SetStakerConfig	24.417s	✅
PackageInstall	18.128s	✅

Test Execution

Operation	Duration	Status
WaitForBeaconchainSync	18.094s	✅
WaitForExecutionSync	2m48.099s	✅

Total Duration: 4m17s

🔴 Container Error Logs

⚠️ Showing up to 3 error lines per container. See CI logs for complete details.

DAppNodePackage-beacon-chain.lodestar-hoodi.dnp.dappnode.eth:

2026-02-06T08:27:02.906784636Z Feb-06 08:27:02.899[chain]            �[33mwarn�[39m: Error processing attestations from block slot=2346049, erroredAttestations=1, code=FORKCHOICE_ERROR_INVALID_ATTESTATION, err=code=UNKNOWN_TARGET_ROOT, root=0x4727344a72e4748634b714e5758b5341d6b7f10c3927e4208e0392cddc74364e
2026-02-06T08:27:02.906808691Z Error: FORKCHOICE_ERROR_INVALID_ATTESTATION
2026-02-06T08:27:02.924400358Z Feb-06 08:27:02.924[chain]            �[33mwarn�[39m: Error processing attestations from block slot=2346050, erroredAttestations=2, code=FORKCHOICE_ERROR_INVALID_ATTESTATION, err=code=UNKNOWN_TARGET_ROOT, root=0x4727344a72e4748634b714e5758b5341d6b7f10c3927e4208e0392cddc74364e

---

📋 View full CI logs

[chong-he]

Should this file name be release.yml?

So this is going to replace the current CI, right? I notice that the current CI somehow stopped scanning for upstream version since 19th Jan (2 weeks ago). So hopefully this will reactivate the scanning of updated version as Lighthouse just released v8.1.0

[pablomendezroyo]

Should this file name be release.yml?

So this is going to replace the current CI, right? I notice that the current CI somehow stopped scanning for upstream version since 19th Jan (2 weeks ago). So hopefully this will reactivate the scanning of updated version as Lighthouse just released v8.1.0

Thanks for the ping, that probably happens due to inactivity

We plan to implement this new CI which includes a syncronization test with real clients installed in dappnode. We plan also to execute sync test + proof of attestation test on every releae

I will document everything in the dappnode devs documentation

[pablomendezroyo]

Should this file name be release.yml?

The workflow that triggers this action was the sync-test.yml, on push it would trigger release.yml, or do you think there is a better naming for these workflow files?

[chong-he]

Should this file name be release.yml?

The workflow that triggers this action was the sync-test.yml, on push it would trigger release.yml, or do you think there is a better naming for these workflow files?

I mean the current file is named as releae.yml

[chong-he]

Should this file name be release.yml?
So this is going to replace the current CI, right? I notice that the current CI somehow stopped scanning for upstream version since 19th Jan (2 weeks ago). So hopefully this will reactivate the scanning of updated version as Lighthouse just released v8.1.0

Thanks for the ping, that probably happens due to inactivity

We plan to implement this new CI which includes a syncronization test with real clients installed in dappnode. We plan also to execute sync test + proof of attestation test on every releae

I will document everything in the dappnode devs documentation

Thanks for the heads up, I see that I can enable the bump upstream version action, I have enabled it now