Skip to content
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
wants to merge 36 commits into
base: master
Choose a base branch
from
Open

Add "download" command. #28

wants to merge 36 commits into from

Conversation

0cjs
Copy link

@0cjs 0cjs commented Jan 6, 2016

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.

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.
0cjs and others added 12 commits January 23, 2016 15:42
* 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.
@0cjs
Copy link
Author

0cjs commented Jan 30, 2016

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.

0cjs and others added 11 commits January 30, 2016 16:53
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
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants