feat(cli): run containerised jstzd with 'sandbox start' #772
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
Completes JSTZ-274.
JSTZ-274
Description
Enable users to run containerised jstzd with
jstz sandbox --container start
.Users can choose to launch the sandbox running containerised jstzd with a newly introduced flag
--container
. All sandbox commands with this flag operates on the container.jstz sandbox --container start
: launch a new container running a pre-defined image with jstzd inside. If the image does not exist, the program then tries to pull that from the repository. This command sets some default config values so that the CLI can interact with the octez node and the jstz node inside the container later on. Note that this command generates some temporary files. They are not going to be cleaned up by the CLI after the sandbox is removed and garbage collection is left to the host OS. It's possible to implement something for this, but I'm not going to do it at the moment just to save some time.jstz sandbox --container stop
: kill the running sandbox container if there is any. This command also cleans up the CLI sandbox config stored locally. I'm not sure why in the old sandbox the sandbox config is not removed when a sandbox is torn down, but I think it makes more sense to clean up the config because every sandbox is new.jstz sandbox --container restart
: restart the sandbox if it exists. Note that this does not raise an error if the sandbox is not running. This command simply prints a reminder message and won't start the sandbox.Note that the module
container
might look a bit awkward. I have to move testable but trivial logic out of the main handlers so that at least we get some test coverage when integration tests are not available.Manually testing the PR