Description
We would like to push as much validation and processing out of the cmd/restorer.go as possible. The cmds are hard to test and keep growing because there is already validation logic present.
Proposed solution
Instead of validating inside of cmd/restorer.go, we should put as much validation as possible into restorer.go. This probably means introducing and using interfaces that wrap file, registry/docker, cache stores, and env access. We should write unit tests to cover and possibly remove validation specific acceptance tests.
Additional context
- We need to keep
creator as well as library authors in mind here a bit. Having group, plan, err := restorer.Restore(cacheStore) makes sense for platforms building on top of lifecycle, like buildkit. So we may wish to introduce new methods that write the files that can optionally be executed by those platforms and always executed by cmd/restorer.go.
Description
We would like to push as much validation and processing out of the
cmd/restorer.goas possible. Thecmdsare hard to test and keep growing because there is already validation logic present.Proposed solution
Instead of validating inside of
cmd/restorer.go, we should put as much validation as possible intorestorer.go. This probably means introducing and using interfaces that wrap file, registry/docker, cache stores, and env access. We should write unit tests to cover and possibly remove validation specific acceptance tests.Additional context
creatoras well as library authors in mind here a bit. Havinggroup, plan, err := restorer.Restore(cacheStore)makes sense for platforms building on top oflifecycle, like buildkit. So we may wish to introduce new methods that write the files that can optionally be executed by those platforms and always executed bycmd/restorer.go.