|James Fenn 5c619e2a11||1 mês atrás|
|.github/workflows||3 meses atrás|
|source||1 mês atrás|
|systemd||3 meses atrás|
|.gitignore||3 meses atrás|
|Makefile||3 meses atrás|
|README.md||3 meses atrás|
|dub.json||3 meses atrás|
|dub.selections.json||3 meses atrás|
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