Add Nix builds for the full registry

[thomashoneyman]

Extends #618 by additionally providing:

• A Nix build for every package that can be run in the registry (the github importer, the registry server, the various scripts like the legacy importer, the package transferrer, etc.)
• A NixOS module that defines a full server. The registry-server service is packaged as a systemd unit. We can deploy this module remotely, to our Digital Ocean NixOS droplet, or we can deploy it to a local VM with nix run. From there you can open localhost:8080 in your browser, or send requests to localhost:8080/api/v1/<path> with something like curl.
• Repository tests as part of the flake checks, so things like code formatting and dhall verification are run the same way locally as they are in CI — and much faster, since Garnix handles both of those checks in ~5 seconds and in parallel.
• A full integration test with a client making requests to the registry server, which is also run in the flake checks. We can expand on this to have a whole suite of integration tests, which I would very much like.

What's the point of all this? In short:

• to be able to run and test the registry server exactly the way it will run on the deployed server, without actually deploying it
• to be able to automatically deploy the server when CI is successful, knowing the integration tests are running on the same system configuration as the deployed target
• to have significantly faster CI with garnix

Note that all packages in the registry can still be run locally. You don't have to use a VM. Things still work fine in the GitHub Actions environment.

You can run any of the existing scripts with their module name swapped to lower-cased, hyphenated attribute names. For example, Registry.Scripts.LegacyImporter:

nix run .#legacy-importer -- dry-run

Or the server (not in a virtual machine), assuming you have your env vars set up properly:

nix run .#server

You can deploy the server to a VM and run it on localhost:8080, and then load that in your browser or curl to the api endpoint:

nix run

You can still get into your Nix shell as usual:

nix develop

[thomashoneyman]

The latest commits add a full integration test using the local VM. That local module definition should also be sufficient to implement deployments to our Digital Ocean server, so I'll take care of that next. At that point all that's left to do is polish this up!

[thomashoneyman]

The latest commit supports deployments to the registry NixOS server on Digital Ocean — you can deploy with colmena apply. The first deployment takes forever because we build on the target machine, and I got an underpowered machine for testing, but subsequent deploys take 2-3 minutes or so if you change the PureScript source code.

Available right now here: http://161.35.111.85

For example:

$ curl 161.35.111.85/api/v1/jobs/0
TODO

Next I'll set up certificates and auto-deploys on commits to master when all the garnix checks complete successfully. At that point we're all set up for continuous deployments.

[thomashoneyman]

I've verified that we can deploy with Let's Encrypt and force secure connections, though with a bare IP address the certs are invalid. I've commented them out, but once we have an e.g. https://registry.purescript.org domain then we can enable it again.

[thomashoneyman]

Note: deployments are working from non-x86_64-linux systems because we're running the build on the server, not locally. However, you won't be able to run the integration test on a darwin system unless you're running a remote builder as per
https://nixos.org/manual/nixpkgs/unstable/#sec-darwin-builder

I'm going to assume no one is doing that so I'm going to disable the integration test for darwin systems.
It will still run in CI, so you can still open a PR to run it. It will also be runnable on any Linux system.

[f-f]

Oh, are we moving away from GH CI entirely??

[thomashoneyman]

We can move away from GitHub CI for our builds and tests because we can run it in Garnix (which also provides a cache our server can use to fetch built code for deployments), but we're still on GitHub Actions for the GitHub-based registry API, the legacy importer, and that sort of thing.

There's simply no need to run the builds & tests in GitHub CI.

[f-f]

Eh, Github is a big org that supports its products for a long time, while Garnix seems to be a one-person operation so far, which is quite less reassuring since we'd be left without CI for test and deployment if it ever turns out to not be a profitable venture.

If we are to switch the CI to Garnix entirely we should at least look into being paying customers, since that helps a bit in guaranteeing that the thing has a viable future.

This is not a theoretical issue - we have been here before with the Travis CI migration, which was quite unpleasant.

[thomashoneyman]

I definitely understand the hesitation around using another CI provider. Travis was indeed a massive hassle.

Fortunately, switching back to GitHub Actions is as simple as adding a workflow line “nix flake check”. It will continue to work, but it will be slower and we will lose our binary cache (again things will work, but be slower). I don’t think there is any significant risk by relying on Garnix.

As far as becoming paying customers — I personally support Garnix via Open Collective (they don’t currently accept payment).

All that said — I'm also happy with going back to GitHub for CI, as it's not a big deal one way or another and you're certainly right that GitHub is going to be more stable and guaranteed to stick around.

[f-f]

Cool, thanks for the details. It sounds like we can easily go back to GH CI if need be, so all good.

I'd like to sponsor Garnix from PureScript's open collective as well if we are relying on it like this.

[f-f]

This looks good - one last thing that we should take care of before merging is some kind of developer documentation, i.e. how to use all of this Nix machinery for folks that are not intimately familiar with Nix and/or with this specific setup.

You added some details in the PR description, but let's have a CONTRIBUTING.md file with instructions on how to run tests, deploy, etc.

[thomashoneyman]

Developer documentation is on the way in the next PR.