fd647002f5
* [monorepo] enable caching for eslint/prettier/stylelint * [monorepo] speed up prettier by swapping --list-different for --check --list-different will print each file that it processes. We have a lot of files in the monorepo. Using --check only prints mismatching files. Co-authored-by: Rebeka <rebeka.dekany@overleaf.com> * [monorepo] explicitly configure prettier cache-location This is the default location. Prettier will only discover that location if the top level node_modules folder is writable, which is not the case in CI. We create the .cache folder outside of docker, writable to node inside docker. The proper fix would be in prettier, to only check for write access in the cache folder. Something to raise/upstream another day. * [monorepo] run top-level format/format_fix in a single container With the cache in place, it is much faster to use a single container. As there is a single shared cache file, concurrent processes may see a partially (re-)written cache file and bail out. - all in a single container: 24s - previous with -j4: 41s - previous with -j8: failed due to corrupted cache file --------- Co-authored-by: Rebeka <rebeka.dekany@overleaf.com> GitOrigin-RevId: 7850a3a980ae6c836393d97fe56a6316ffc3fa18
Migrations
Migrations for the app environment live in this folder, and use the East migration framework.
We have a npm script which wraps east: npm run migrations -- ...
For example:
npm run migrations -- list -t 'server-ce'
For SAAS, use the rake tasks for staging/production
rake deploy:migrations:list[staging]
Environments and Tags
Overleaf is deployed in three different environments:
server-ce: community edition installations (the base system)server-pro: server pro installationssaas: the production overleaf site
All migrations are tagged with the environments they should run in.
For example, a migration that should run in every environment would be tagged with ['server-ce', 'server-pro', 'saas'].
When invoking east, we specify the relevant tags with the -t or --tags flag.
Our adapter will refuse to run if this flag is not set.
Creating new migrations
To create a new migration, run:
npm run migrations -- create <migration name>
This command will create a new migration file in the migrations folder, based on a template. The template provides
migrate and rollback methods, which are run by the east binary when running the migrations. rollback should
undo the changes made in migrate.
Running scripts as a migration
To run a script in a migration file, look at migrations/20190730093801_script_example.js, which runs the script
scripts/example/script_for_migration.mjs. This uses a method where the script can be run standalone via node, or
through the migrations' mechanism.
Running migrations
To run all migrations in a server-ce environment:
npm run migrations -- migrate -t 'server-ce'
# Note: They are run by default on container start.
To run all migrations in a SAAS environment use the rake task:
# list first and check that only your newly added migration is shown. If not, ask in the dev channel for help.
rake deploy:migrations:list[staging]
# After confirming the listing, run the migrations
rake deploy:migrations[staging]
To run all migrations in the dev-env:
make services/web/migrate
# Note: "make install" will pick them up as well
The -t flag also works with other east commands like rollback, and list.
For other options, or for information on how to roll migrations back, take a look at the East documentation.
Tips
Try to use Mongo directly via the db object instead of using Mongoose models. Migrations will need to run in the
future, and model files can change. It's unwise to make the migrations depend on code which might change.
Note: Running east rollback without any arguments rolls back all migrations, which you may well not want.