feat: add Swagger / OpenAPI, plus refactor (#6)

* Intermediate state

* feat: add error

* Rework complete

* Remove unused Result type

Cargo.toml

@@ -4,29 +4,29 @@ version = "0.1.0"
 edition = "2021"
 
 [dependencies]
-# atmosphere = { version = "0.1.3", features = ["sqlite"] }
+atmosphere = { version = "0.2.0", features = ["sqlite"] }
 axum = { version = "0.7.4", features = ["macros", "http2"] }
 axum-extra = { version = "0.9.2", features = ["typed-header"] }
-color-eyre = "0.6.2"
 dotenv = "0.15.0"
 dotenv_codegen = "0.15.0"
 eyre = "0.6.12"
 jsonwebtoken = "9.2.0"
 mime = "0.3.17"
 serde = { version = "1.0.196", features = ["derive"] }
 serde_json = "1.0.113"
-sqlx = { version = "0.7.3", features = ["runtime-tokio", "sqlite"] }
+sqlx = { version = "0.7.3", features = ["runtime-tokio", "sqlite", "migrate"] }
+thiserror = "1.0.57"
 tokio = { version = "1.36.0", features = ["full"] }
 tracing = "0.1.40"
 tracing-subscriber = { version = "0.3.18", features = ["env-filter"] }
-
-[dependencies.atmosphere]
-git = "https://github.com/bmc-labs/atmosphere.git"
-branch = "main"
-default-features = false
-features = ["sqlite"]
+tracing-test = "0.2.4"
+utoipa = { version = "4.2.0", features = ["axum_extras"] }
+utoipa-swagger-ui = { version = "6.0.0", features = ["axum"] }
 
 [dev-dependencies]
 http-body-util = "0.1.0"
 pretty_assertions = "1.4.0"
 tower = "0.4.13"
+
+[profile.release]
+lto = "thin"

README.md

@@ -9,34 +9,41 @@
 
 </div>
 
-If you're running GitLab runners in Docker and you're looking for a simple, non-manual way of doing so, runrs has you covered. You can run runrs in your Docker alongside the GitLab Runners control service - it just needs access to the configuration file containing Runner configs and things will _just work™_.
-
-
-## Quickstart
-
-_some instructions for how to run it locally for testing_
+If you're running GitLab runners in Docker and you're looking for a simple, non-manual way of doing
+so, runrs has you covered. You can run runrs in your Docker alongside the GitLab Runners control
+service - it just needs access to the configuration file containing Runner configs and things will
+_just work™_.
 
 
 ## Motivation
 
-Running GitLab Runners in Docker is simple, but managing them - adding new ones, cleaning up, rotating them - is an annoying manual task. If you're anything like us, you don't like those. Moreover, it's something we don't do _that often_ - a few times per month perhaps - so we end up looking up the manual steps in the GitLab docs every godforsaken time. Meanwhile, pretty much everything else we run is Terraformed, which makes this doubl-y annoying.
+Running GitLab Runners in Docker is simple, but managing them - adding new ones, cleaning up,
+rotating them - is an annoying manual task. If you're anything like us, you don't like those.
+Moreover, it's something we don't do _that often_ - a few times per month perhaps - so we end up
+looking up the manual steps in the GitLab docs every godforsaken time. Meanwhile, pretty much
+everything else we run is Terraformed, which makes this doubl-y annoying.
 
-Thus, we wrote this simple service which provides a CRUD API for GitLab Runner configurations and can run in Docker, managing the Runners configuration file. We also have [a Terraform provider]() you can use to _GitLab Runner Setup as Code_ your Runners.
+Thus, we wrote this simple service which provides a CRUD API for GitLab Runner configurations and
+can run in Docker, managing the Runners configuration file. We also have [a Terraform provider]()
+you can use to _GitLab Runner Setup as Code_ your Runners.
 
 
-## Using runrs
+## Using runrs in prod
 
-_instructions on how to get set up for real, and a link to an actual example_
+We don't recommend you do (just yet).
 
 
 ## Local Development Setup
 
-It's a fairly Rust and `cargo` project, so if you have that up and running, you should be good. For testing, also a Docker would be great. But hey, I mean, you do you.
+It's a vanilla Rust and `cargo` project, so if you have a recent (1.75+) Rust toolchain installed,
+you should be good. For testing end to end, you'll need:
 
-### Prerequisites
+- Docker, which is going to be used as the executor for your runners, up and running, and
+- `gitlab-runner`, either installed and running locally or running in Docker. The docs for
+  installing it are [here](https://docs.gitlab.com/runner/install/osx.html).
 
-- well, git
-- a recent (1.75+) Rust toolchain
+Configuration is done via the `.env` file in the repo. We know that that's bad, and we intend to fix
+that, but remember we also told you we don't recommend running this in prod yet, so yeah.
 
 ### Setup
 
@@ -57,7 +64,8 @@ That's it. Make a PR with your changes and we'll talk about them.
 
 ## Support
 
-This is an open source project, so there isn't support per se. If you open an issue in the repository, we'll try and help you, but no promises.
+This is an open source project, so there isn't support per se. If you open an issue in the
+repository, we'll try and help you, but no promises.
 
 ---
 

clippy.toml

@@ -0,0 +1 @@
+warn-on-all-wildcard-imports = true

migrations/20240203134208_runners.down.sql

@@ -0,0 +1,2 @@
+-- Copyright 2024 bmc::labs GmbH. All rights reserved.
+DROP TABLE IF EXISTS runners;

migrations/20240203134208_runners.up.sql

@@ -0,0 +1,10 @@
+-- Copyright 2024 bmc::labs GmbH. All rights reserved.
+CREATE TABLE IF NOT EXISTS runners (
+    id           INTEGER PRIMARY KEY,
+    url          TEXT    NOT NULL,
+    token        TEXT    UNIQUE NOT NULL,
+    description  TEXT    NOT NULL,
+    image        TEXT    NOT NULL,
+    tag_list     TEXT    NOT NULL,
+    run_untagged BOOLEAN NOT NULL
+);

rustfmt.toml

@@ -1 +1,3 @@
-imports_granularity = "Crate"
+unstable_features = true
+imports_granularity = "Module"
+group_imports = "StdExternalCrate"