Closed mwvaughn closed 3 years ago
I will begin work on this in the actors init
command
Functionality for apps init
is currently as follows on branch feat-350-init-dry-run
:
$ tapis apps init APPY --debug --app-version 1.0.0 \
--app-description "If you are appy and you know it clap your hands" --dry-run
+-------+-----------------------------------------------------------------------------------+
| stage | message |
+-------+-----------------------------------------------------------------------------------+
| setup | Project path: ./appy |
| setup | CookieCutter variable name=APPY |
| setup | CookieCutter variable description=If you are appy and you know it clap your hands |
| setup | CookieCutter variable version=1.0.0 |
| setup | CookieCutter variable project_slug=appy |
| setup | CookieCutter variable docker_namespace=sd2e |
| setup | CookieCutter variable docker_registry=https://index.docker.io |
| setup | Workflow stopped because this is a dry run |
+-------+-----------------------------------------------------------------------------------+
Completed and merged as of 18e0b5c9fbc1efb469e229ee074d5df4cb752d3c
Problem
apps init
andactors init
workflows send a dynamically populated dictionary of key-value pairs to an instance ofcookiecutter()
to create a new project from a template. The dictionary is populated by reading the local environment but also by reading the CLI's settings, so from a user's point of view it might not be 100% clear how and what variables are being sent to cookiecutter for interpretation.Proposed Solution Implement a "dry run" function, accessible via
-R, --dry-run
(same as for thedeploy
workflow) that will a. Present all dynamically generated key:value pairs b. Inspect the filesystem to determine whether it is possible to create a new projectNotes Ideally, identical implementation and behavior will exist between the
apps init
andactors init
implementations. Later on, we may want to factor some of the logic into a parent class.