-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "download" command. #28
Open
0cjs
wants to merge
36
commits into
danthareja:master
Choose a base branch
from
cynic-net:master
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This can only be run after an "init"; it downloads the current code from Google. Typically you'd want to use this to check that the code you're working with is up to date with what's on Google.
* Prefix a slash to all patterns expected to be only in root of project. * Suffix a slash to all patterns expected to be directories. * `tmp/` is used as a scratch directory by developers. * `.build/` is for files generated by the build/test system.
…perly. * Bring in gulp to do our build/test stuff, give it a "test" and "unit-test" targets (the former depending on the latter). * Use tape to run the unit tests, and faucet to pretty-print the results. (Still a bit verbose when there are no errors.)
We use a standard TAP functional test format with `tNNN*.js` test scripts under a `t/` subdirectory. These can be run directly from the project root with `node t/t001.js` or similar, and later the build system will be extended to find and run tests automatically. The `t/tlib.js` file is a library of handy support functions for this, including bringing it various test tools (tape, tape-spawn, etc.) and functions to read in data files that store expected output and whatnot. tlib itself is tested with `t/t001-tlib.js`. The first test of the non-test-framework code is `t010-version.js`, which proves we can run the `gapps` binary.
The functional tests depend on the unit tests to prevent interleaving the output of unit-test and functional-test tasks.
This initializes from a publicly readable apps script project made available on Google Drive. The user will have to have done his own gapps authorization first.
Lots of testing stuff added. Since I need to make new features available via npm soon, I'll be changing the name of this project shortly. Those changes will appear on this pull request if you don't close it soon, so you may want to grab things now or remember, later, not to take all the commits. |
We're effectively forking the project here as our development path (and even some current features, e.g., the "download" command) are moving in a different direction from the one in which danthareja wants to go. The command-line tool is renamed to `gas`, to avoid conflict with those who have projects that use the `gapps` tool. The local configuration file for the GAS projects is renamed to avoid confusion and because we'll soon be changing the format, but we will continue to use the `$HOME/.gapps` file for Google Drive authentication information until we expand the format of that to handle multiple accounts. We did a quick pass over the README to fix up the most obvious things related to the rename, but there's much more to be done there.
…s called. Use bluebird's promisify to allow use to call spawn a second time after the first process finished.
We don't use it yet on the other code because it doesn't conform to our style guidelines yet and thus produces a lot of errors.
Tape (and at least some things that use it, such as tape-spawn) ensures that tests run one-at-a-time and in order. Thus, we don't need to use promises to enforce this; we can just put the tests in a particular file in dependency order. This actually isn't terribly pretty or comfortable, but it's the best we've got for now.
I'm not sure what this is used for exactly. It's clearly not that important considering that the official documention for it is out of date. It seems simple enough to put back in if need be.
The only additional things this is checking is the parsing of arguments and how it passes the config to the promises. I don't know enough about promises and mocking in JS to be able to write a unit test for this.
I'm afraid to touch init, because it's untested and I don't understand the manifest code.
…selves * Removes the need to hard code the REST API path * Gives better error messages since errors are thrown as JSON objects, instead of HTML that needs to be parsed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This can only be run after an "init"; it downloads the current code
from Google. Typically you'd want to use this to check that the code
you're working with is up to date with what's on Google.
This is a resolution to Issue #27. There's a bit of refactoring that could
still be done here, especially with the duplicated function, but it wasn't
clear to me that
lib/manifestor.js
was the right place for this function.