Align config structure with other public testnet repositories

[pk910]

Align the metadata folder with the structure of other public testnets (holesky, devnets):

• Add EL genesis configs (genesis.json, chainspec.json, besu.json)
• Remove comments from bootstrap_nodes.txt (not allowed by some clients)
• Add yaml version of cl bootnodes list: bootstrap_nodes.yaml (needed by some clients, with comments)
• Add el bootnodes list as plain list (enodes.txt) and commented yaml (enodes.yaml)

I've tested the EL genesis files with 3 client pairs (geth/lighthouse, nethermind/lighthouse & besu/lighthouse).
All pairs were able to start sync the mainnet chain with the supplied configs (without using the built in configs)

Rel:
sepolia: eth-clients/sepolia#89
holesky: eth-clients/holesky#111

[arnetheduck]

Add yaml version of cl bootnodes list: bootstrap_nodes.yaml (needed by some clients, with comments)

Add el bootnodes list as plain list (enodes.txt) and commented yaml (enodes.yaml)

An explicit feature of unifying the shape of network metadata was to avoid duplicated yaml/txt files since historically, these were going out of sync with each other.

As such, the better option here would be to raise issues with affected clients instead f duplicating the information - it doesn't matter which of yaml and txt it is, as long as there is one only - there exists no inherent benefit to storing the same information redundantly in two, for this purpose, equivalent formats.

[pk910]

Heya @arnetheduck,

Yea, I see the problem with files getting out of sync and tend to agree with the general approach to not duplicate the bootnode files.
However, we can't fully prevent these duplicates for the el bootnodes, as some genesis configurations include the el bootnodes as well (besu.json & chainspec.json).

So, what about if we add a check workflow that runs on PRs to the genesis repositories and checks if the bootnodes are in sync in all files?
That way we can easily ensure these files keep in sync.

I'll also gonna remove the txt files, as the yaml is a properly standardized format that can be parsed with standard tools (taking care of comments, etc.).
Most of the problems I was facing with the missing txt versions is actually coming from our toolings and the way how we pass bootnodes to our devnet clients, so it's not super critical to not have them.

[arnetheduck]

So, what about if we add a check workflow that runs on PRs to the genesis repositories and checks if the bootnodes are in sync in all files?

sounds rube-goldbergish but sure. they could just fix their shit too though.

I'll also gonna remove the txt files, as the yaml is a properly standardized format that can be parsed with standard tools (taking care of comments, etc.).

again, I don't greatly care which, but text file with # for comments is also pretty universally a standard, and an awful lot more simple than a full yaml parser which is probably the reason why most of the tooling you refer to supports that and not the yaml (ie you can easily manipulate it with shell scripts even).

[pk910]

I've removed the txt versions and added a workflow that runs on PRs to main and checks:

• the el & cl bootnodes for duplicates
• the el bootnodes for consistency across the el genesis files (chainspec.json & besu.json)

@arnetheduck are you fine with that trade off?

[arnetheduck]

is this really all there is? 4 bootnodes?

[arnetheduck]

not sure why, but actions is not picking up the workflow