The current way this CLI tool is set up only allows you to use the standard 'production' and 'staging' environments that we normally use in our deployment workflows.
To make this more flexible it would be better if you create any number of environments and be able to do the normal commands with any.
Example:
If you'd set up a third environment called 'testing', you would be able to do:
toward assets push -e testing
Proposed Solution
In the .toward file, it would use the first part of the variable names as the environment name.
Example:
If I had the following variables added after the normal vars for production and staging environments in the .toward file...
TESTING_SERVER_IP=
TESTING_SERVER_ADDRESS=
TESTING_SERVER_USERNAME=
TESTING_SITE_DIRECTORY=
TESTING_DATABASE_NAME=
TESTING_DATABASE_USERNAME=
TESTING_DATABASE_PASSWORD=
...then it would automatically understand to use these vars when I ran the command toward assets push -e testing
The current way this CLI tool is set up only allows you to use the standard 'production' and 'staging' environments that we normally use in our deployment workflows.
To make this more flexible it would be better if you create any number of environments and be able to do the normal commands with any.
Example:
If you'd set up a third environment called 'testing', you would be able to do:
toward assets push -e testingProposed Solution
In the .toward file, it would use the first part of the variable names as the environment name.
Example:
If I had the following variables added after the normal vars for production and staging environments in the .toward file...
...then it would automatically understand to use these vars when I ran the command toward assets push -e testing