Commit graph

13 commits

Author SHA1 Message Date
Halla Moore 87aa1a86ad [*] Make sure cloud deploy can access .babelrc
Summary:
Now that .babelrc is in client-app, we need to make it an exception in the
.dockerignore file. Additionally, this means that the client-app directory will
exist during the postinstall script in the cloud environment, so we need a
stricter check to figure out if the client-app needs to be built or not.

Test Plan: deployed to staging

Reviewers: evan, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D4008
2017-02-22 12:09:14 -08:00
Juan Tejada 1485575e48 [client-app] Fix build
Partially revert 3071856a8e

Symlinking instead of copying the error-logger-extensions prevents the
app from finding the appropriate dependencies required in the error
logger extensions in the main process and in the renderer processes
because globalPaths are only set in renderer processes and /after/
error-logger-extensions are loaded.

We should fix this properly in a separate diff, and move the error
logger to isomorphic-core instead of copying it or symlinking it
2017-02-21 15:57:38 -08:00
Halla Moore 1105b2621f [*] Rename postinstall.js -> postinstall.es6
The n1Cloud machines try to compile this script, even though they
never run it, and they didn't recognize it was supposed to be es6
2017-02-21 15:55:08 -08:00
Evan Morikawa 3071856a8e [client-app] symlink in babelrc and resolve links
Summary:
The prod build was failing because it couldn't find the .babelrc.

I decided to put the babelrc in the main nylas-mail repo with the
expectation that it'll need to be in the open source version too. To DRY
up this for us building, we sylink the root one to the client-app babelrc

Also since we now dereference symlinks we don't need to do the full copy
of nylas-private-resources so we don't have two error reporters floating
around

Test Plan: npm run build-client

Reviewers: juan, spang

Reviewed By: juan, spang

Differential Revision: https://phab.nylas.com/D3993
2017-02-21 16:08:59 -05:00
Evan Morikawa 4582acc2e5 [client-app] actually npm install inside the /apm dir with env vars
Summary:
We weren't actually running npm install inside of apm. This meant that
/apm/node_modules was empty causing the build to fail. This will install
with the proper env required for old apm

Wow we need to get rid of this thing soon…

Test Plan: Run `npm install`

Reviewers: jerm, spang, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D3986
2017-02-21 14:34:30 -05:00
Juan Tejada c8a299ed9b [*] Correctly copy error logger extensions in postinstall script
Summary: Also fix linter errors

Test Plan: manual

Reviewers: evan, mark, halla

Reviewed By: halla

Subscribers: halla

Differential Revision: https://phab.nylas.com/D3960
2017-02-17 12:12:56 -08:00
Evan Morikawa b686b969cd [cloud-*] Get cloud-api and cloud-workers running on new repo
[dev] remove .tern-project

[cloud-*] move into cloud-core/build

[cloud-core] convert to launch properly via Docker
2017-02-17 11:47:45 -08:00
Evan Morikawa 918fa0b6dd [*] move to monorepo
[*] update babel

[client-app] remove flow-typed

[client-app] Move build/package.json to main package.json

[client-app] remove spec_integration

[client-app] fix babel support

Add client-private-plugins package.json

[client-app] add node_modules to global path for private-plugins

Move client-sync dependencies to client-app root

fix electron rebuild

[*] moved to monorepo

Summary: App now runs in monorepo

Test Plan: npm test

Reviewers: juan, mark, khamidou, halla, spang

Differential Revision: https://phab.nylas.com/D3947
2017-02-16 18:46:26 -08:00
Karim Hamidou e55c36a79a [cloud-api] Add support for database migrations
Summary:
This diff adds support for database migration to our cloud API. It's partially inspired by Halla's local-sync migration diff (D3809). You can run a migration by calling "node-babel scripts/migrate-db up|down" or by calling "npm script upgrade-db|downgrade-db".

Note that for simplicity reasons we assume that we're only writing migrations for our MySQL database – people developing locally may have to blow up there dbs whenever there's a schema change, though in practice `ALTER TABLE ADD COLUMN`statements work the same on both dbs.

Test Plan: Tested locally. Will run the metadata migration on staging.

Reviewers: evan, spang, halla

Reviewed By: halla

Differential Revision: https://phab.nylas.com/D3840
2017-02-06 13:38:59 -08:00
Christine Spang 5e99f7fa21 run-redis.sh must be run under bash 2017-02-06 13:13:22 -08:00
Karim Hamidou ae32666609 [cloud-api] Base infrastructure for running cloud workers
Summary:
I've decided to break my snooze patches in multiple parts to make it easier to review. This diff contains all the code related to running workers in the cloud. Cloud workers all inherit from the `Worker` class which defines a bunch of useful things like error handling.

What's left to do:
- spawn workers based on the plugin type
- add monitoring (I'm going to add a simple HTTP endpoint for that)
- writing a migration for the local sync db and the prod metadata db.

Test Plan: Tested manually.

Reviewers: halla, evan

Reviewed By: evan

Differential Revision: https://phab.nylas.com/D3814
2017-02-02 16:14:59 -08:00
Juan Tejada f56a807792 [cloud-*] Fix n1-cloud build
We added new presets and plugins to the k2 .babelrc but didn't add the
respective dependencies in our package.json, so the build was failing.

Add the required dependencies, and make sure that `build-n1-cloud.js`
uses the correct babel presets and plugins
2017-01-28 02:00:16 -08:00
Evan Morikawa 1d254a7aaa [*] Add basic babel toolchain
Summary:
Adds babel to K2
Creates a simple build script so it'll run on prod.

Test Plan: manual

Reviewers: jackie, halla, juan

Reviewed By: juan

Differential Revision: https://phab.nylas.com/D3527
2016-12-16 13:08:21 -05:00