|
|
||
|---|---|---|
| .. | ||
| api | ||
| backupVerifier | ||
| benchmarks | ||
| config | ||
| migrations | ||
| storage | ||
| test | ||
| .gitignore | ||
| .mocharc.json | ||
| .nvmrc | ||
| app.js | ||
| backup-deletion-app.mjs | ||
| backup-verifier-app.mjs | ||
| backup-worker-app.mjs | ||
| buildscript.txt | ||
| docker-compose.ci.yml | ||
| docker-compose.yml | ||
| Dockerfile | ||
| install_deps.sh | ||
| knexfile.js | ||
| Makefile | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
Database migrations
The history service uses knex to manage PostgreSQL migrations.
To create a new migrations, run:
npx knex migrate:make migration_name
To apply migrations, run:
npx knex migrate:latest
For more information, consult the knex migrations guide.
Global blobs
Global blobs are blobs that are shared between projects. The list of global blobs is stored in the projectHistoryGlobalBlobs Mongo collection and is read when the service starts. Changing the list of global blobs needs to be done carefully.
Adding a blob to the global blobs list
If we identify a blob that appears in many projects, we might want to move that blob to the global blobs list.
- Add a record for the blob to the projectHistoryGlobalBlobs collection.
- Restart the history service.
- Delete any corresponding project blobs.
Removing a blob from the global blobs list
Removing a blob from the global blobs list is trickier. As soon as the global blob is made unavailable, every project that needs the blob will have to get its own copy. To avoid disruptions, follow these steps:
-
In the projectHistoryGlobalBlobs collection, set the
demotedproperty tofalseon the global blob to remove. This will make the history system write new instances of this blob to project blobs, but still read from the global blob. -
Restart the history service.
-
Copy the blob to all projects that need it.
-
Remove the blob from the projectHistoryGlobalBlobs collection.
-
Restart the history service.