What
In epic #706, an automated release evaluation framework is established. Two of the four tests use a number of assets stored in S3:
- from apply-load live ingestion test:
- golden DB:
current/golden.sqlite.zst
stellar-core: core/stellar-core.zst- 3 ledger bundles:
ledgers/load-test-ledgers-*.xdr.zst
- from backfill ingestion test:
stellar-core: core/stellar-core.zst (same as above)
On a monthly cadence, the DB in current/ should be replaced by a freshly-backfilled DB; the current should be moved into prev1/, the DB in prev1/ should be moved into prev2/, and the DB in prev2/ should be evicted. Alternatively, whenever the backfill test is run and successful and the golden DB is older than ~2 weeks, this sequence should initiate. The prev*/ folders will probably need to be established, along with some logic to defer back to these DBs if the DB in current/ is corrupted.
On that same cadence, one should likely have the 3 ledger bundles be regenerated using apply-load machinery in stellar-rpc, and have the old replaced with the new.
Then, on some cadence (likely matching stellar-core releases), the prebuilt binary should be updated. Alternatively, rather than using a prebuilt binary, one could set this up to pull the latest from stellar/stellar-core.
Why
These assets are made semi-constant to avoid constant drift between assets. With that said, they should still be periodically refreshed to ensure the test stays up-to-date.
What
In epic #706, an automated release evaluation framework is established. Two of the four tests use a number of assets stored in S3:
current/golden.sqlite.zststellar-core:core/stellar-core.zstledgers/load-test-ledgers-*.xdr.zststellar-core:core/stellar-core.zst(same as above)On a monthly cadence, the DB in
current/should be replaced by a freshly-backfilled DB; the current should be moved intoprev1/, the DB inprev1/should be moved intoprev2/, and the DB inprev2/should be evicted. Alternatively, whenever the backfill test is run and successful and the golden DB is older than ~2 weeks, this sequence should initiate. Theprev*/folders will probably need to be established, along with some logic to defer back to these DBs if the DB incurrent/is corrupted.On that same cadence, one should likely have the 3 ledger bundles be regenerated using
apply-loadmachinery instellar-rpc, and have the old replaced with the new.Then, on some cadence (likely matching
stellar-corereleases), the prebuilt binary should be updated. Alternatively, rather than using a prebuilt binary, one could set this up to pull the latest fromstellar/stellar-core.Why
These assets are made semi-constant to avoid constant drift between assets. With that said, they should still be periodically refreshed to ensure the test stays up-to-date.