Merge branch 'dev' into feature/231-dev-email

.github/workflows/bundlewatch.yml

@@ -34,7 +34,7 @@ jobs:
         echo "::set-output name=dir::$(npm config get cache)"
 
     - name: Restore npm cache directory
-      uses: actions/cache@v2.1.0
+      uses: actions/cache@v2.1.1
       with:
         path: ${{ steps.npm-cache.outputs.dir }}
         key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

.github/workflows/lint.yml

@@ -21,7 +21,7 @@ jobs:
         echo "::set-output name=dir::$(npm config get cache)"
 
     - name: Restore npm cache directory
-      uses: actions/cache@v2.0.0
+      uses: actions/cache@v2.1.1
       with:
         path: ${{ steps.npm-cache.outputs.dir }}
         key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

docs/deployment.md

@@ -160,6 +160,42 @@ This transport will work automatically when running via Docker Compose, accessib
    [transports]: https://github.com/search?q=nodemailer+transport
    [mail-senders]: /server/email/senders.js
 
+
+## Database Migrations
+
+When we need to update the Polis database, we use SQL migration files.
+
+During initial provisioning of your Docker containers, all the migrations will
+be applied in order, and you won't need to think about this.
+
+But if we update the database schema after your initial provisioning of your
+server via Docker, you'll need to manually apply each new SQL migration.
+
+- Please note: **Backups are your responsibility.** These instructions assume
+  the data is disposable, and do not attempt to make backups.
+    - Pull requests are welcome if you'd like to see more guidance on this.
+- Your database data is stored on a docker volume, which means that it will
+  persist even when you destroy all your docker containers. Be mindful of this.
+    - You can remove ALL volumes defined within a `docker-compose` file via: `docker-compose down --volumes`
+    - You can remove ONE volume via `docker volume ls` and `docker volume rm <name>`
+- SQL migrations can be found in [`server/postgres/migrations/`][] of this
+  repo.
+- The path to the SQL file will be relative to its location in the docker
+  container filesystem, not your host system.
+
+For example, if we add the migration file
+`server/postgres/migrations/000001_update_pwreset_table.sql`, you'd run on your
+host system:
+
+```
+docker-compose exec postgres psql --username postgres --dbname polis-dev --file=/docker-entrypoint-initdb.d/000001_update_pwreset_table.sql
+```
+
+You'd do this for each new file.
+
+   [`server/postgres/migrations/`]: /server/postgres/migrations
+
+
 ## Contribution notes
 
 Please help us out as you go in setting things up by improving the deployment code and documentation!

server/Dockerfile-db

@@ -1,3 +1,6 @@
 FROM postgres:12.4-alpine
 
-COPY ./postgres/db_setup_draft.sql /docker-entrypoint-initdb.d/
+# Used when no existing database on postgres volume, including first initialization.
+# See: docs/deployment.md#database-migrations
+# See: https://github.com/docker-library/docs/blob/master/postgres/README.md#initialization-scripts
+COPY ./postgres/migrations/*.sql /docker-entrypoint-initdb.d/

server/postgres/db_setup_draft.sql → server/postgres/migrations/000000_initial.sql

@@ -335,11 +335,11 @@ CREATE TABLE zinvites (
 CREATE INDEX zinvites_zid_idx ON zinvites USING btree (zid);
 
 -- TODO flush regularly
-CREATE TABLE pwreset_tokens (
+CREATE TABLE password_reset_tokens (
     uid INTEGER REFERENCES users(uid),
     created BIGINT DEFAULT now_as_millis(),
-    token VARCHAR(250),
-    UNIQUE (token)
+    pwresettoken VARCHAR(250),
+    UNIQUE (pwresettoken)
 );
 
 CREATE TABLE beta(

server/postgres/migrations/000001_update_pwreset_table.sql

@@ -0,0 +1,2 @@
+ALTER TABLE password_reset_tokens RENAME COLUMN pwresettoken TO token;
+ALTER TABLE password_reset_tokens RENAME TO pwreset_tokens;