Larger cage projects often have some associated shell scripts, many of which call back into cage repeatedly to perform some task like database seeding with specific (larger than usual) data sets.
@dkastner and I have discussed having a cage script command:
cage script load-data full
This would call $PROJ/scripts/load-data full, but with a few wrinkles:
It would be able to run recursive cage commands, preserving the --target and -p options by default.
It would have some sort of sensible policy about .cage/pods and other cage state, perhaps sharing them between separate invocations of cage.
Would this offer enough value to be worth the complexity?
There doesn't seem to be a lot of enthusiasm (or need) for this yet, so I'm going to close this issue. But if anybody has a use-case, please feel free to re-open it!
Larger cage projects often have some associated shell scripts, many of which call back into cage repeatedly to perform some task like database seeding with specific (larger than usual) data sets.
@dkastner and I have discussed having a
cage script
command:This would call
$PROJ/scripts/load-data full
, but with a few wrinkles:--target
and-p
options by default..cage/pods
and other cage state, perhaps sharing them between separate invocations ofcage
.Would this offer enough value to be worth the complexity?