Closed sphuber closed 3 months ago
@danielhollas would something like this work?
Attention: Patch coverage is 88.88889%
with 2 lines
in your changes missing coverage. Please review.
Project coverage is 77.83%. Comparing base (
ef60b66
) to head (6459592
). Report is 127 commits behind head on main.
Files with missing lines | Patch % | Lines |
---|---|---|
src/aiida/cmdline/commands/cmd_storage.py | 88.89% | 2 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
Overall this makes sense, I'll have a closer look later. Also want to do some benchmarks to see if this is indeed an improvement. For a profile without a broker (after #6550), running verdi storage migrate
and verdi storage version
takes roughly the same amount of time (which makes sense)
`❯ hyperfine -w 5 'verdi storage version' 'verdi storage migrate --force'
Benchmark 1: verdi storage version
Time (mean ± σ): 737.2 ms ± 4.7 ms [User: 749.3 ms, System: 812.7 ms]
Range (min … max): 729.5 ms … 745.8 ms 10 runs
Benchmark 2: verdi storage migrate --force
Time (mean ± σ): 763.7 ms ± 7.3 ms [User: 779.1 ms, System: 811.5 ms]
Range (min … max): 758.6 ms … 783.0 ms 10 runs
Summary
verdi storage version ran
1.04 ± 0.01 times faster than verdi storage migrate --force
Fixes #6547
The
verdi storage version
, in addition to printing the version of the code's and storage's schema, now also validates the storage. If the storage is corrupt or cannot be reached, the command returns the exit code 3. If the storage and code schema versions are incompatible, exit code 4 is returned. This way this command serves as an alternative to runningverdi storage migrate
as a way to check whether a profile needs to be migrated. Theverdi storage migrate
command needs to perform checks such as whether the daemon is running and so is always going to be slower.