TobiasDeBruijn
commented
1 year ago Binary is the default yep. I usually build for musl libc (as I usually run my software on Alpine images). I'm not at all familiar with Nix, so I prefer not to set that up. While I'd love to learn it eventually, I currently don't have the time to do so.
Installing docker is adding the docker apt repo and apt install, it's not too much effort, but more than just a regular binary.
If Nginx is already running, then the frontend via that is definitely the easiest. Both the docs and the frontend compile to a static website.
I'll work on setting up a CI pipeline on GH Actions for the following then:
- Running tests on the backend (still need to write a lot of those though)
- Run format tests & the linter on the backend
- Build a static binary of the frondend, possibly a docker container, and produce tar.gz's for the docs and frontend.
I think I'll be able to get this done over the weekend, or Monday.
Riscky
This is written as an answer to https://github.com/svsticky/chroma/issues/1#issuecomment-1453646998
We can probably get this up and running quickly if we can build a binary for the backend. Building this binary on CI on the same Ubuntu version as the servers run should save us from linking woes, or we could produce a static binary of course. We also use the Nix package manager on our servers, so if you could build a Nix derivation that would work great too. We could also use the Docker container, but we haven't set up Docker on our servers (I'm not sure how much effort this would cost, but it's more then just running
apt install). I think it is easiest to just build a binary.As the frontend is a static website, we can just serve the build with nginx, no problem. We could even do continuous delivery for that, similar to how https://github.com/svsticky/static-sticky has been set up. We currently don't have a specific place where we host docs, but if we have a static website, it's easy enough to host it somewhere.
To make this a proper issue:
We should set up a CI pipeline, probably in Github actions (which we use everywhere). This CI should run the linters and builds. We can upload build artifacts (of tagged commits) as GitHub releases (or on S3, but I think it's more in the spirit of open source software to publish your builds publicly). For the frontend and the docs, this can be a tar.gz with the static website. For the backend, this should be either a Nix derivation (stored in Cachix), a binary (this is my preference) or a Docker image (probably uploaded to Dockerhub?).
@TobiasDeBruijn if you need help with setting up Github Actions, I'd be glad to help.