Bring a dev facility forward

This page moves a serving dev facility onto the working tree as it is now, after the code has changed under it. Most changes need nothing from you: the server is rebuilt as its source changes, and the bundler rebuilds the client. Three kinds of change are not picked up on their own, and this page is those three.

A dev facility runs one release, the working tree, so there is no release to point it at and no copy of its database taken first. If a change goes wrong, the recovery is to build the facility again from its dump, which is the last section.

After pulling code

cd "$ZFM_ROOT_DIR"
git pull
npm install

The install is a no-op when the lock file did not change, and the only safe way to find out when it did.

When the contract changed

A change to shared/ reaches the server and the client only as a build. The service that builds it is a one-shot, so run it again:

systemctl --user restart zfm-shared
systemctl --user status zfm-shared     # active (exited)

The server's watcher picks the new build up. Metro exits when the directory is rebuilt under it and is started again by its service, so give it a moment before reloading the browser.

When a migration was added

A server refuses to serve a facility whose database is not the shape it expects, and writes what the two disagree about to its journal instead. So a pulled migration leaves the facility's server restarting every few seconds until the schema is brought forward:

cd "$ZFM_ROOT_DIR/zf-server"
FACILITY=<facility> npm run migration:show
FACILITY=<facility> npm run migration:run
systemctl --user restart zfm-server@<facility>

migration:show lists the chain with a mark against each step already applied, so you can see what is about to run. The restart is because a server that was refusing to start has nothing to watch.

Am I ready to move on?

curl -s localhost:<port>/health
journalctl --user -u zfm-server@<facility> -n 20

The version in the answer is the working tree's, from git describe, and the journal's last lines are a server that started rather than one that refused.

When in doubt, build it again

Everything a dev facility holds came from a dump and a settings file, so nothing in it is worth protecting, and the clean way back from any state is the way it was built:

cd "$ZFM_ROOT_DIR"
scripts/rebuild-dev-facility.sh <facility>
systemctl --user restart zfm-server@<facility>

Take a fresh dump first, with scripts/dump-prod-facilities.sh <source>, when it matters that the records are recent. The restart is because the server's database connections are to tables that no longer exist.