|James Fenn 5c619e2a11||7 months ago|
|.github/workflows||9 months ago|
|source||7 months ago|
|systemd||9 months ago|
|.gitignore||9 months ago|
|Makefile||9 months ago|
|README.md||8 months ago|
|dub.json||9 months ago|
|dub.selections.json||9 months ago|
Usage: horrific <command> [options...] Where <command> is one of: hello list-ports reserve-port release-port
This ridiculous program is used to manage the projects that run on HorrificDev servers, create CI workflows based on webhooks, and track resource usage.
Each repository should contain a
horrific.yml configuration file that specifies how it should be deployed on the server.
horrific CLI actually runs as two processes; a systemd service running with root permissions, and a client process started by the user. These processes communicate through a D-Bus interface configured in source/daemon.d.
The configuration for this service is defined in systemd/horrific.service; the horrific.conf file defines its D-Bus configuration, and dev.horrific.daemon.service allows it to be recognized and started by the system D-Bus session whenever a message is sent.
In each repo the program is configured for must be a
horrific.yml file that details how the program should be invoked.
Here's an overcomplicated example of a potential configuration, hosting a static site (compiled with [arbitrary site generator in the form of a Jenkins pipeline]) at
horrific.dev and a NodeJS app at
services: - name: Website type: static run: - preset: jekyll working_dir: /web serve: ssl: certbot domains: - horrific.dev - name: Backend / API type: docker run: - preset: nodejs working_dir: /api ports: - 8080 serve: ssl: certbot domains: - api.horrific.dev