-
Notifications
You must be signed in to change notification settings - Fork 584
[CI] Rename berkeley debian suffix to testnet-generic #18112
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: compatible
Are you sure you want to change the base?
[CI] Rename berkeley debian suffix to testnet-generic #18112
Conversation
|
!ci-nightly-me |
|
!ci-build-me |
1 similar comment
|
!ci-build-me |
|
!ci-build-me |
1 similar comment
|
!ci-build-me |
| "./scripts/docker/build.sh" | ||
| ++ " --service ${Artifacts.dockerName spec.service}" | ||
| ++ " --network ${Network.lowerName spec.network}" | ||
| ++ " --network ${Network.debianSuffix spec.network}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the interesting stuff:
network name is added as a segment of debian name which must follow some rules, like no underscore. That's why we are using explicit method to convert network to debian suffix
| # This config is automatically picked up by the daemon on startup. | ||
| # In case of testnet-generic we only copy the devnet ledger without magic one | ||
| # as testnet-generic should be testnet agnostic. | ||
| case "${1}" in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another interesting part:
We are no longer adding genesis ledgers to every package variation (from network perspectvie). Mainnet to mainnet, devnet to devnet, testnet-generic got devnet.
Also we are not adding magic config to testnet generic
|
!ci-build-me |
|
!ci-build-me |
3 similar comments
|
!ci-build-me |
|
!ci-build-me |
|
!ci-build-me |
830737a to
cdf3bef
Compare
|
!ci-build-me |
cdf3bef to
a796817
Compare
|
!ci-build-me |
…g up magic config to testnet-generic debian
a796817 to
041fd63
Compare
|
!ci-build-me |
|
!ci-build-me |
|
!ci-build-me |
|
!ci-nightly-me |
| cp ../genesis_ledgers/${1}.json "${BUILDDIR}/var/lib/coda/${1}.json" | ||
| ;; | ||
| testnet-generic) | ||
| cp ../genesis_ledgers/devnet.json "${BUILDDIR}/var/lib/coda/devnet.json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will still require testnet-generic deployments to delete this in order to start new custom ledgers, right? @dkijania
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this ledger is not automatically included when you are staring daemon. The one you are referring is located in /var/lib/coda/config_{commit}.json. That is why we are omitting such copy (like we are doing in 199 line)
Introducing testnet-generic docker/debian packages instead of berkeley.
Historically berkeley artifacts were used for long runing pre hf testnet for experimenting with berkeley prior to hardfork event. After that we were still using them as genesis config for berkeley (see for example discussion here: #17537 (comment)). The main reason to keep berkeley artifacts and still build them in CI, was not obvious. Since we didn't fork from berkeley , genesis config does not contain hard fork element, which is irreplaceable by chain of configs when running daemon, in contrary to devnet/mainnet. That would be fixed by full runtime config implementation, where we can replace every element of genesis config.
Till then, I'm proposing to replace berkeley with something more clear as per usage and rename it to testnet-generic. We need testnet prefix to suggest it is incompatible with mainnet and generic since it is not binded to any network. By default seed list is targeted to devnet but there is no genesis config loaded behind the scenes. Therefore such artifacts can interact in any testnet network.
Important things in this pr are: