Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upDeploy subcommand for CLI tool #23
Conversation
ogoding
added some commits
Mar 2, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 17, 2016
Contributor
I was also planning on including the option of specifying the deploy directory, but I think that could wait for some time in the future.
|
I was also planning on including the option of specifying the deploy directory, but I think that could wait for some time in the future. |
White-Oak
and others
added some commits
Mar 17, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 22, 2016
Contributor
@White-Oak Ah, so now Vec<&str> are ArgMatches interchangeable for the commands? Cool. I'll have a look at merging from master when it lands vec!["--release", "--color=always"] to test and build.
|
@White-Oak Ah, so now Vec<&str> are ArgMatches interchangeable for the commands? Cool. I'll have a look at merging from master when it lands |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
White-Oak
Mar 22, 2016
Contributor
@ogoding those commands already supply color=always and instead of --release, you'll need to supply release to them (that's what they're looking for).
|
@ogoding those commands already supply |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ebkalderon
Mar 22, 2016
Member
@White-Oak Pull request #24 looks pretty good to me. @ogoding, what are your thoughts? Whose PR should I merge first to minimize breakage?
|
@White-Oak Pull request #24 looks pretty good to me. @ogoding, what are your thoughts? Whose PR should I merge first to minimize breakage? |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
White-Oak
Mar 22, 2016
Contributor
@ebkalderon #24 is going to be merged first, since @ogoding 's work is dependent on this.
|
@ebkalderon #24 is going to be merged first, since @ogoding 's work is dependent on this. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 23, 2016
Contributor
@ebkalderon Merging it now, just trying to work out how to call/import the new methods from the deploy Cmd struct at the moment.
|
@ebkalderon Merging it now, just trying to work out how to call/import the new methods from the deploy Cmd struct at the moment. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 23, 2016
Contributor
@ebkalderon Should be merged without issue now! Will try to finish off the conversion from std;:io::Error to &str and then it'll all be finally done!
|
@ebkalderon Should be merged without issue now! Will try to finish off the conversion from |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
LucioFranco
Mar 23, 2016
Member
@ogoding I have some work done with that. Would you like me to give you a small PR that removes the tryio! macro so we can just use try! everywhere and not have that borrow issue.
|
@ogoding I have some work done with that. Would you like me to give you a small PR that removes the |
White-Oak
reviewed
Mar 23, 2016
| +impl AmethystCmd for Cmd { | ||
| + /// Compresses and deploys the project as a distributable program. | ||
| + fn execute<I: AmethystArgs>(matches: &I) -> cargo::CmdResult { | ||
| + let cargo_args = vec!["--release"]; |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
White-Oak
Mar 23, 2016
Contributor
Once again, build and test subcommands look for release argument, not --release.
White-Oak
Mar 23, 2016
Contributor
Once again, build and test subcommands look for release argument, not --release.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 23, 2016
Contributor
@LucioFranco That'd be great, thanks. Hopefully you don't have any conflicts, but I suspect you might.
|
@LucioFranco That'd be great, thanks. Hopefully you don't have any conflicts, but I suspect you might. |
ogoding
added some commits
Mar 23, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
LucioFranco
Mar 23, 2016
Member
@ogoding I am almost ready with the new error system. Expect a PR within the next 20. (Hopefully) :)
|
@ogoding I am almost ready with the new error system. Expect a PR within the next 20. (Hopefully) :) |
LucioFranco
and others
added some commits
Mar 23, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 23, 2016
Contributor
@ebkalderon PR is finally all done! Let me know if there is anything else that I should improve.
|
@ebkalderon PR is finally all done! Let me know if there is anything else that I should improve. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
Wonderful job! I'll try it out on my laptop tomorrow. |
ebkalderon
referenced this pull request
Mar 24, 2016
Merged
Check for most commands if the project is an amethyst project #25
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ebkalderon
Mar 24, 2016
Member
@ogoding The generated resources.zip file structure seems incorrect when deploying an empty project on my laptop.
Currently it results in:
resources.zipresources/(folder)entities(zero-length file)prefabs(zero-length file)config.yml(file)input.yml(file)
resources(zero-length file)
It should be:
resources.zipentities/(folder)prefabs/(folder)config.yml(file)input.yml(file)
|
@ogoding The generated Currently it results in:
It should be:
|
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 24, 2016
Contributor
@ebkalderon hmm, I'll have a look at it. Probably that resources file is due to walkdir using the given path as the first file/folder it iterates.
|
@ebkalderon hmm, I'll have a look at it. Probably that resources file is due to |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ogoding
Mar 26, 2016
Contributor
@ebkalderon Just pushed a fix for those compression issues. Turns out that rust doesn't include a / character at the end of a directory's path. Also WalkDir starts in the current directory so I had to change it back to fs::read_dir(path) and use WalkDir for any sub directories in resources/.
|
@ebkalderon Just pushed a fix for those compression issues. Turns out that rust doesn't include a / character at the end of a directory's path. Also |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
|
@ogoding Testing it now... |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
ebkalderon
Mar 28, 2016
Member
@ogoding It works perfectly! Thank you so much for your effort and patience. I think this pull request is finally ready to be merged.
|
@ogoding It works perfectly! Thank you so much for your effort and patience. I think this pull request is finally ready to be merged. |
ogoding commentedMar 17, 2016
Implements the
deploysubcommand.deploycleans the relevanttargetdirectory, runs tests and builds the project. It then creates adeploydirectory, zips all files (including the directory itself) inresources, and copies all dynamically linked libraries and binaries todeploy.