| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
otherwise it just fails to start with an error
|
|
|
|
|
|
|
|
|
|
| |
this allows setting options via an environment file that is passed to
the systemd units, in addition to the ones set during build time of the
package.
For now this is tailored to SECRET_KEY, but it may be useful for other
settings as well (e.g. EMAIL_HOST_PASSWORD), and I'm not sure if it
takes priority over the build-time settings ...
|
|
|
|
|
|
|
|
| |
this should be mostly usable for actual deployments. Only thing that's
really still annoying is having to set the SECRET_KEY via Nix, since
not having set it makes the package fail to build. But it doesn't
actually end up in the derivation, so changing it afterwards should be
fine; I've just not tested that yet.
|
| |
|
|
|
|
|
|
|
| |
this is still missing:
- a nice way to do settings
- lots of testing (run the manage.py test script in a nixos test?)
- an actual way to deploy this in a halfway reasonable way
|
| |
|
|
|
|
| |
(just messing around for now)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
not tested, but like, why not? Might be fun playing around with it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
this packages the heartwood cli tools, the radicle web interface, and
runs a small example deployment on chaski.
TODO: decide if i want to keep this thing, then add declarative config
of the web interface, `rad auth`, and the radicle node to a NixOS
module; the current state is kinda suboptimal to deploy.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
apparently the default homeserver this uses is not configurable???
… might hack around later
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
constantly rebuilding the world just got too annoying
|
|
|
|
|
| |
might have to revert this if it causes problems, or if rebuilding all
the things annoys me too much.
|
| |
|
| |
|
|
|
|
|
| |
setting elixir = elixir_1_14 may get me trouble later, we'll see
(version bounds on bahnhof.name's search engine are weird)
|
| |
|
|
|
|
|
|
|
|
| |
in gleam, because why not?
(tbf i will probably eventually rewrite this in a more sensible
language; I haven't even found any reason to use any of the OTP features
for this 🙈)
|
| |
|
|
|
|
|
|
| |
this file has been lying around for a bit over a year now, but I got
asked about it, so time to put it in the public repo I guess (& also
update it; it's on the most recent travelynx commit as of this writing).
|
| |
|
|
|
|
|
|
| |
please no one like, actually use this. unless you volunteer to at least
add a script to run database migrations, since currently these need to
be run by hand …
|
|
|
|
|
| |
the only thing this makes more complicated is typst; most of the other
benefits I don't use in any case.
|
| |
|
|
|
|
| |
i don't know why i did this. i literally have no use for it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
Since pleroma is in nixpkgs 21.05, this requires some reshuffling to
keep the unstable version of pleroma (otherwise the database versions
are not compatible, and pleroma does not like database downgrades).
Additionally, hedgedoc's database has been moved to a postgres user who
is actually called hedgedoc.
|
| |
|
|
|
|
|
|
|
|
|
| |
This pleroma config should be able to set itself up without any
manual intervention (modulo the secrets file, which is almost empty).
Annoyingly, the pleroma nixpkg is built from the pipeline artifacts
of the pleroma gitlab and does not have support for pleroma's ssh/bbs
mode.
|
|
This deploy logic is primarily based on hxchn's deploy lib [1], with some
slight modifications to make it work with my setup. Everything seems to work
fine for now.
However, I am unsure about the usage of niv — the config doesn't seem to gain
much from it, apart from (some) additional complexity.
[1] https://gitlab.com/hexchen/nixfiles
|