Replayer, check snarked ledger hash, berkeley cron job #13715
Conversation
|
!ci-build-me |
|
!ci-build-me |
| @@ -151,7 +151,7 @@ dhall_types: ocaml_checks | |||
|
|
|||
| replayer: ocaml_checks | |||
| $(info Starting Build) | |||
| ulimit -s 65532 && (ulimit -n 10240 || true) && dune build src/app/replayer/replayer.exe --profile=testnet_postake_medium_curves | |||
| ulimit -s 65532 && (ulimit -n 10240 || true) && dune build src/app/replayer/replayer.exe --profile=devnet | |||
There was a problem hiding this comment.
hard-coding the profile may create a conflict within CI for file /buildkite/scripts/build-artifact.sh.
This file uses dune build "--profile=${DUNE_PROFILE}" with ${DUNE_PROFILE} being set within the CI pass. If there is any odd behavior with CI replayer tasks, this could be relevant.
There was a problem hiding this comment.
We've used a hard-coded profile here for a long time. I changed the profile, because the ledger depth has changed.
I'll keep an eye out for any issues that arise.
| TODAY_CHECKPOINT=berkeley-replayer-checkpoint-$DATE.json; | ||
| mv $DISK_CHECKPOINT $TODAY_CHECKPOINT; | ||
| echo "Uploading checkpoint file" $TODAY_CHECKPOINT; | ||
| gsutil -o Credentials:gs_service_key_file=/gcloud/keyfile.json cp $TODAY_CHECKPOINT gs://berkeley-replayer-checkpoints/$TODAY_CHECKPOINT; |
There was a problem hiding this comment.
Within CI, there is a $RELEASE value that is set, which could be used to target the network (berkeley/mainnet/...).
buildkite/scripts/export-git-env-vars.sh.
I do notice the file itself is berkeley-specific, so this maybe is not a problem. Feel free to disregard this and the previous comment if the file is not shared within CI or in other places.
There was a problem hiding this comment.
Only used for cron job, not CI.
|
!ci-build-me |
|
!ci-build-me |
|
!approved-for-mainnet |
psteckler
deleted the
feature/berkeley-replayer-cronjob-snarked-ledger-check
branch
Add snarked ledger check to replayer: each snarked ledger is the ledger hash from some first-pass application of a transaction.
There's a hole, though. If replaying from a checkpoint, the transaction that created the ledger hash may have occurred before the checkpoint. We can close that hole by saving pending ledger hashes to the checkpoint file, if desired, but I'd prefer to defer that to a subsequent PR.
Add the YAML file to run a replayer cron job on berkeley.
Tested the cron job by manually running it.
Made some monad uses a little more concise, because I could.
Closes #13463.
Closes #13700.