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-nethermind.dnp.dappnode.eth	0.1.12
Consensus	nimbus-hoodi.dnp.dappnode.eth	0.1.3
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	Nethermind/v1.36.0+31cb81b7/linux-x64/dotnet10.0.1
After Install	Nethermind/v1.36.0+31cb81b7/linux-x64/dotnet10.0.1

Consensus Client Versions

Stage	Version
Before Install	Nimbus/v25.9.2-9839f1-stateofus
After Install	Nimbus/v25.9.2-9839f1-stateofus

⏱️ Timing Measurements

Environment Setup

Operation	Duration	Status
SetStakerConfig	41.257s	✅
PackageInstall	16.786s	✅

Test Execution

Operation	Duration	Status
WaitForBeaconchainSync	6.001s	✅
WaitForExecutionSync	12.012s	✅

Total Duration: 1m41s

---

📋 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