stuebinm
e12cc7dbf5
This jumps Mattermost ESR Versions (see [1] for their release cycle). The new version makes use of Go's workspace feature, which unfortunately the buildGoModule function does not (yet?) support [2], and unfortunately this breaks the previous build process for mattermost. Further, the new release also makes use of private modules only included in the (non-free) enterprise version of mattermost which makes it impossible to build in the usual way even outside of nixpkgs's build abstractions [3]. Both issues can be solved by using Go 1.22, which has added support for vendoring when using workspaces, and instructing it to ignore errors with the -e flag. This requires overriding the go-modules derivation's buildPhase. Finally, this now also build the commands/mmctl subpackage, which contains a cli utility to administrate mattermost. This currently has its own nixpkgs package for no reason i can see at all (it also has a version mismatch between nixpkgs's mattermost and nixpkgs's mmctl). [1] https://docs.mattermost.com/upgrade/extended-support-release.html [2] https://github.com/NixOS/nixpkgs/issues/203039 [3] https://github.com/mattermost/mattermost/issues/26221 |
||
|---|---|---|
| common | ||
| docs | ||
| modules | ||
| parsons | ||
| pkgs | ||
| websites | ||
| .gitignore | ||
| .rgignore | ||
| .sops.yaml | ||
| LICENSE | ||
| README.md | ||
| flake.lock | ||
| flake.nix | ||
| secrets.yaml | ||
README.md
hacc nixfiles
Welcome to the hacc nixfiles (haccfiles). This is how we configure (most of) our infrastructure.
General layout
flake.nix: Entrypoint & dependenciesmodules/: home-grown modules for hacc-specific servicespkgs/: packages we need which aren't in nixpkgswebsites/: static websites hosted by uscommon/: meta-level config, reusable across machinesparsons/: our sole server, its config & the services it runs
Right now, we only have a single host. We might add more again in the future.
Working with this repo
You will need a flake-enabled nix installation, and have your ssh config set up
so that ssh parsons will connect to parsons.hacc.space.
Deploying remotely
It's recommended to use deploy_rs:
deploy .#parsons -k [--dry-activate]
Alternatively, using just nixos-rebuild:
nixos-rebuild --flake .#parsons --target-host parsons \
--use-remote-sudo --use-substitutes [test|switch|dry-activate]
Re-deploying on parsons itself
Simply do:
nixos-rebuild --flake .#parsons [test|switch|dry-activate]
Working on websites
Websites are exposed as flake outputs: if you're working on a website & want to check it in a browser, do e.g.
nix run .#\"muc.hacc.earth\"
to start a local http server (note that some of our websites need a directory
to be built in; these use /tmp/hacc-website).
To add a new website, add a new subdirectory to websites; nix will generate a
vhost config based on that directory's name. Add a default.nix in your directory
describing how to build the website, and give its derivation a watch attribute
to make the nix run setup work.
I don't want to build this long dependency / want a cached version!
If it's still available on parsons from a previous deploy, do:
nix copy --from ssh://parsons /nix/store/...
Note: don't just copy the .drv file (which Nix complains about if it can't
build something), that's just the description of how to build it! If you
don't know the actual outpath, look in the .drv file (should start with
Derive([("out","[the path you want]"...)
committing to haccfiles
- Things on
mainshould always reflect the config that's actually deployed on parsons, except during testing / debugging sessions - split up commits, every commit is one atomic change
- follow the commit format: "place: $change"
- place: e.g.
modules/$module,services/$service... - change: describe your change. Please wrap your lines sensibly (or configure your editor to do this for you)
- place: e.g.
- Exception: autogenerated messages (merge commits, reverts, etc)
- don't overuse merge commits, try to rebase things if possible with reasonable effort