Closed hhsnopek closed 10 years ago
Haven't had enough time to implement - closing for now
no problem @HHSnopek , thank you for even taking the time out to put your thoughts on paper. @slang800 is going to spend some time to work on ship and give it the attention it deserves - I'm sure he'll take the ideas you mentioned here into consideration.
:+1:
Yesterday morning(1/19) I discovered a way to re-organize ship.
I'm introducing/renaming a couple of variables:
default.coffee
default.coffee remains the same, takes the arg_parser() and gives us our cargo, deployer, config, & origin. The config is still true/false:
deployer
)arg_parser.coffee
With arg_parser.coffee I'm going to attempt to use arg.js instead of the current.
deployer.coffee
deployer.coffee will be called from default.coffee. This will take the, passed, variables(see below) and initiate deploying. vars:
This is a where we add md5sum.coffee which will complete the md5sum of all files within the cargo, using a serial loop. md5sum will call ignore_contents and remove all the contents that aren't supposed to be shipped.
md5sum.coffee
md5sum.coffee is in charge of creating the md5 sums of all the contents as well as creating an array(sorted by path) of specified contents to be shipped.
Using a serial loop, it'll recursively create an array of the file structure, then through regex(or another method), remove the contents to ignore. Basically while the loop runs, it checks if the file is within ignores, if it is it'll skip it. If the file isn't within ignores it'll push it to the array and create an md5 sum for it.
The md5 sums will be added to ship.conf(bottom), see https://github.com/carrot/ship/issues/16
Edit: After looking at this, it's gonna be a huge mess... I think a single line object would be better(maybe json): The path to the files(
main.css
) within a folder(turns into/css/main.css
) can be added when hashing.I believe I'll have to have a couple of functions for the serial loop, here's why. There will be another serial loop that is going to create a new set of hashes from the new cargo, and match/run against the old set of hashes. If this loop is ran, it'll return the new cargo to send(which will update accordingly).
This will return the updated cargo to ship.
deployers(overall)
My main purpose of the re-organization is to rewrite how ship.conf is constructed. I like how each deployer specifies it's configuration details. I'd like to reference the configuration details from the specified deployer when creating/updating ship.conf. Instead of each deployer taking care of the configuration setup, the deployers will only check if the settings for itself are present, deploy, and return errors.
Thoughts?