The Gogs developers got it into their head that trying to write things
to some relative path from the binary location is a sensible thing to
do (spoiler: it's not).
Due to their weird "GOGS_CUSTOM" directory which seems to only
sometimes be configurable by environment variables, the command used
to handle SSH requests failed because it attempted to write logs into
the Nix store.
This works around the issue by hardcoding the log file root path in
the Gogs configuration.
Now that Hunchentoot is serving the Elm frontend, Elm needs to connect
to Gemma at a relative path.
Side note: It would be useful if the frontend displayed errors that
happened :sun:
In order to let Hunchentoot serve the static assets from the correct
location, the *static-file-location* parameter is set before image
dumping based on the $out-envvar which is present during the build
process.
This can easily be set manually in the config file if required by a
user.
Adds a build script using ASDF's program-op to build an executable out
of the Gemma source code.
In addition a Nix derivation is provided that will both compile the
Elm source and place it in a folder, as well as create the executable.
Currently static file serving does not function as intended.
Adds configuration loading from a file located at either
"/etc/gemma/config.lisp" or a path determined via the `GEMMA_CONFIG`
environment variable.
The configuration file can contain any number of deftask forms and a
single config form which determines the location at which Gemma stores
its data and also the port on which it should listen.
Uses the cl-prevalence system to store tasks on disk. The storage
location is either relative to the working directory in which the
system is started or determined (with priority) by the environment
variable `GEMMA_DATA_DIR`.
Adds a clickable area to the cards that will inform the backend of a
task being completed.
This of course still looks completely terrible because I don't really
know how frontend works.