Filing separately from #524 since (I guess) we already have a job record, all information is available to rerun any particular prior reproman run, so that commit message record could be oriented more toward human readability (e.g., become yaml instead of json ;))
Inspired by the successful runs of the demo workflow of #438 , it seems to be time to consider implementing a rerun functionality. Since we are not creating datalad run records (although it could have been done with command being some reproman-run shim etc - but probably too ad-hoc and inflexible? or am I wrong?), I guess we are doomed to develop reproman rerun.
Unlike datalad run, I think it would make sense to allow for reproman rerun to change (replace) some of the recorded parameters (e.g. resource, submitter, orchestrator; batch params etc), so it could be very easy to fulfill use cases such as
reproman rerun --bp "pl=newsubject" - "do the same by on new subject(s) data"
`reproman rerun --jp "container=fmriprep-1.6.0" - do the same by using another registered versioned container
reproman rerun -r cloud1 --bp "pl=10:20", reproman rerun -r cloud2 --bp "pl=20:30" to run new subjects spreading across two cloud resources
or of cause
reproman rerun --since= for a similar to pure datalad rerun reproducible execution.
Filing separately from #524 since (I guess) we already have a job record, all information is available to rerun any particular prior
reproman run
, so that commit message record could be oriented more toward human readability (e.g., become yaml instead of json ;))Inspired by the successful runs of the demo workflow of #438 , it seems to be time to consider implementing a
rerun
functionality. Since we are not creatingdatalad run
records (although it could have been done with command being somereproman-run
shim etc - but probably too ad-hoc and inflexible? or am I wrong?), I guess we are doomed to developreproman rerun
.Unlike
datalad run
, I think it would make sense to allow forreproman rerun
to change (replace) some of the recorded parameters (e.g. resource, submitter, orchestrator; batch params etc), so it could be very easy to fulfill use cases such asreproman rerun --bp "pl=newsubject"
- "do the same by on new subject(s) data"reproman rerun -r cloud1 --bp "pl=10:20"
,reproman rerun -r cloud2 --bp "pl=20:30"
to run new subjects spreading across two cloud resourcesor of cause
reproman rerun --since=
for a similar to puredatalad rerun
reproducible execution.