Open pbchase opened 6 years ago
This issue could be broken down into as many as four releases in a series of incremental improvements. That series might look like this:
Deploy and enable one module. This is the minimally functional feature.
Deployment Usage:
fab vagrant deploy_module:ctsit/imagemap
fab vagrant deploy_module:ctsit/imagemap,1.2.1
fab vagrant deploy_module:ctsit/imagemap,,0.0.0
fab vagrant deploy_module:ctsit/imagemap,1.2.1,0.0.0
fab vagrant deploy_module:'https://github.com/ctsit/imagemap
Enable Usage:
fab vagrant enable_module:imagemap
fab vagrant enable_module:imagemap,0.0.0
fab vagrant enable_module:imagemap,1.2.1
fab vagrant enable_module:'https://github.com/ctsit/imagemap'
Deploy and enable multiple modules. This feature would be driven by the existing modules.json. It would be implemented via these methods.
Deploy and enable only as needed. This is an incremental deployment and enabling of modules. It would require these methods:
Additionally, the deploy_modules
and enable_modules
methods would need to be revised to consume the inputs acquired by these modules and not deploy or enable where that work was already done.
Deploy pre-release code. It might be useful to test unreleased code in a non-local environment. To do that we would need a method, deploy_module_from_directory
.
To get the inputs for get_latest_release_tag
and get_latest_release
, consider these examples:
# to enumerate releases in json
curl -L -s 'https://api.github.com/repos/ctsit/redcap_webservices/tags'
# to download a release
curl -L -s https://github.com/ctsit/redcap_webservices/archive/1.0.3.zip -O
Module updates that are done using Fabric tools have a tedious, multi-step workflow as shown here.
The fabric tools could benefit from a task designed to deploy and enable a module from a code release. See the green text above.