2015-08-03 23:19:32 +03:00
|
|
|
#!/bin/bash
|
|
|
|
set -euo pipefail
|
|
|
|
# This script is run every time an instance of our app - aka grain - starts up.
|
|
|
|
# This is the entry point for your application both when a grain is first launched
|
|
|
|
# and when a grain resumes after being previously shut down.
|
|
|
|
#
|
|
|
|
# This script is responsible for launching everything your app needs to run. The
|
|
|
|
# thing it should do *last* is:
|
|
|
|
#
|
|
|
|
# * Start a process in the foreground listening on port 8000 for HTTP requests.
|
|
|
|
#
|
|
|
|
# This is how you indicate to the platform that your application is up and
|
|
|
|
# ready to receive requests. Often, this will be something like nginx serving
|
|
|
|
# static files and reverse proxying for some other dynamic backend service.
|
|
|
|
#
|
|
|
|
# Other things you probably want to do in this script include:
|
|
|
|
#
|
|
|
|
# * Building folder structures in /var. /var is the only non-tmpfs folder
|
|
|
|
# mounted read-write in the sandbox, and when a grain is first launched, it
|
|
|
|
# will start out empty. It will persist between runs of the same grain, but
|
|
|
|
# be unique per app instance. That is, two instances of the same app have
|
|
|
|
# separate instances of /var.
|
|
|
|
# * Preparing a database and running migrations. As your package changes
|
|
|
|
# over time and you release updates, you will need to deal with migrating
|
|
|
|
# data from previous schema versions to new ones, since users should not have
|
|
|
|
# to think about such things.
|
|
|
|
# * Launching other daemons your app needs (e.g. mysqld, redis-server, etc.)
|
|
|
|
|
|
|
|
mkdir -p /var/lib/hledger
|
2016-11-15 23:57:29 +03:00
|
|
|
touch /var/lib/hledger/Ledger
|
2015-08-04 01:31:18 +03:00
|
|
|
cd /var
|
2018-06-24 18:44:22 +03:00
|
|
|
hledger-web --capabilities-header=X-Sandstorm-Permissions --serve --base-url='' -f /var/lib/hledger/Ledger --port 8000
|