nóssa

Phoenix/LiveView app hosting the website you’re looking at.

I wanted to host my software on my own turf, in my own way. This is the result. I’m hoping to add some nice interop to make collaboration easier; particularly things like ForgeFed and Friendly Forge Format (F3).

recursos / features

In most cases the answer to your question is “why not?”.

• git2-rs-based repository access for web views.
• git-http-backend interface supporting smart transport/v2.
• LiveView frontend, with full support for non-JavaScript clients.
• Extensive test coverage.
• Comprehensive support for non-UTF-8 branch names, commit messages, filenames.
• Localised, with English and LATAM Spanish to start.

See TAREAS.md for a list of things yet to be done!

desenvolvimento / development

The development and build process assumes you are able to use Nix flakes¹.

Use nix develop to enter a dev shell. The first time you’re getting set up you’ll want to do a mix deps.get; we use Mix normally in dev, and then use deps_nix to make them reproducible for production builds.

Then:

• make pg — starts Postgres with a database stored in ./db.
• make server — runs the Phoenix server in IEx.
• make testwatch — runs mix test every time a relevant file changes.
• make coverwatch — runs mix test --cover every time a relevant file changes.

The last two also can take ARGS=....

construindo para produção / building for prod

• nix build will produce a Mix release in result.
• nix build .#nossa-docker will create a Docker image which can be run directly, or as part of an orchestration setup.
  • nix build .#packages.x86_64-linux.nossa-docker-jmsingle uses some special support for building x86_64 Linux Docker images on aarch64 Darwin hosts, which (without modification) would normally trap due to attempted double-mapping of JIT. It forces the equivalent of +JMsingle true by patching the Erlang used for nóssa and all dependencies.

There’s a NixOS module included, which can be used to deploy nóssa with a few lines of configuration. To do this, add the input to your own flake.nix:

nossa = {
  url = "git+https://nossa.ee/~talya/nossa";
  # Add as desired:
  # inputs.nixpkgs.follows = "nixpkgs";
  # inputs.flake-utils.follows = "flake-utils";
  # inputs.rust-overlay.follows = "rust-overlay";
};

Then include the nossa.nixosModules.${system}.nossa module. You can now configure a nóssa installation per nix/module.nix:

services.nossa = {
  enable = true;
  port = 8000;                     # for your reverse proxy.
  metricsPort = 8001;              # prometheus-style metrics.
  host = "your-nossa.ee";          # hostname nóssa runs on.
  secretKeyBaseFile = somePath;    # secret key base for Phoenix.
  erlangCookieFile = anotherPath;  # cookie for Erlang.
  maxBodyLength = 1000000000;      # max push size via HTTP.
};

nóssa avoids running its own epmd, so you will want to be running your own:

services.epmd.enable = true;

If you want to be able to connect to your running nóssa service, add the binary to your system path:

environment.systemPackages = [config.services.nossa.package];

Note that you’ll need to specify the path to the cookie in the environment to connect successfully. For example:

$ RELEASE_COOKIE="$(cat /run/secrets/erlang-cookie)" nossa remote

See the Distributed Erlang — Security section of the Erlang documentation for more details sobre o biscoito mágico.

There’s also a deprecated module included to deploy it into a NixOS-managed k3s environment, but I’ll probably replace this with an actual Helm chart.

1. I am so sorry but I can’t find a single good link that would actually just take you through using them. It’s true what they say about Nix people. Try the Nix flakes page from Zero to Nix. It doesn’t really get any better than that. ↩