Repository navigation
chore: use 3.1.1 migration baselines - #311
piotr-iohk wants to merge 2 commits into
Conversation
talosmachina
left a comment
There was a problem hiding this comment.
No findings. Moves the Android and iOS native migration baselines from 3.1.0 to 3.1.1 and records the 3.1.1 archive digests. Reviewed 61fa986, light tier.
What I checked, and 3 candidates I ruled out
Read in full: config/migration-baselines.json, config/migration-checksums.json, and their readers scripts/migration-matrix.py (migration_plan) and scripts/download-migration-app.py (download)
CI: this repo runs no checks on the branch. The two hosted migration runs linked in the body were still in_progress when I looked.
Not run: talos-pr-run could not confirm the author's permission on this repo, so I did not execute the branch; this review is static plus the asset checks below. Both JSON files parse.
Ruled out
- Digest mismatch: both new values equal GitHub's own
digestforbitkit_e2e.apkandBitkit.app.zipon the 3.1.1 release, and the release'sSHA256SUMS.txt. - Asset name or tag drift:
download()fetchesreleases/download/<version>/<asset>with the asset namesbitkit_e2e.apkandBitkit.app.zip, and looks upchecksums[<version>][<asset>]; the new3.1.1key and both asset names match the release. - Helper tests pinned to the old baseline:
test_migration_tools.pywrites its own fixture baselines since #299, so the bump needs no test change.
Merge confidence: 4/5, a config value checked against the release, but the hosted migration runs it cites had not finished.
Future Android and iOS migration runs should start from the shipped 3.1.1 native release. Advance both defaults to 3.1.1 and record the SHA-256 digests of the archived regtest APK and iOS simulator ZIP. Keep historical checksums and React Native v1.1.6 coverage.
Hosted validation uses this PR's default pins and the standard RN cases. The targets are the 3.1.1 version-bump branches because both current masters still build 3.1.0.
Land the native version bumps before switching the default baseline so scheduled migration runs have compatible install-over targets.