docs: some changed; removed some old files

docs/api/source/includes/_git.md

@@ -112,7 +112,7 @@ Parameter | Description
 url | URL of the Git repository.
 branch | Branch of the Git repository.
 repo | Vieter repository to publish built packages to.
-schedule | Cron build schedule
+schedule | Cron build schedule (syntax explained [here](https://rustybever.be/docs/vieter/usage/builds/schedule/))
 arch | Comma-separated list of architectures to build package on.
 
 ## Modify a repo

docs/content/CLI.md

@@ -1,27 +0,0 @@
-# Vieter CLI
-
-I provide a simple CLI tool that currently only allows changing the Git
-repository API. Its usage is quite simple.
-
-First, you need to create a file in your home directory called `.vieterrc` with
-the following content:
-
-```toml
-address = "https://example.com"
-api_key = "your-api-key"
-```
-
-You can also use a different file or use environment variables, as described in
-[Configuration](/configuration).
-
-Now you're ready to use the CLI tool.
-
-## Usage
-
-* `vieter repos list` returns all repositories currently stored in the API.
-* `vieter repos add url branch repo arch...` adds the repository with the given
-  URL, branch, repo & arch to the API.
-* `vieter repos remove id` removes the repository with the given ID prefix.
-
-You can always check `vieter -help` or `vieter repos -help` for more
-information about the commands.

docs/content/configuration.md

@@ -47,14 +47,6 @@ configuration variable required for each command.
     * Git repositories added without an `arch` value use this value instead.
 
 
-### `vieter repos`
-
-* `api_key`: the API key to use when authenticating requests.
-* `address`: Base your URL of your Vieter instance, e.g. https://example.com
-* `base_image`: image to use when building a package using `vieter repos
-  build`.
-    * Default: `archlinux:base-devel`
-
 ### `vieter cron`
 
 * `log_level`: log verbosity level. Value should be one of `FATAL`, `ERROR`,
@@ -87,7 +79,8 @@ configuration variable required for each command.
   how frequently (in minutes) to rebuild this builder image.
     * Default: `1440` (every 24 hours)
 * `global_schedule`: build schedule for any Git repository that does not have a
-  schedule defined. 
+  schedule defined. For information about this syntax, see
+  [here](/usage/builds/schedule).
     * Default: `0 3` (3AM every night)
 
 ### `vieter logs`
@@ -95,17 +88,11 @@ configuration variable required for each command.
 * `api_key`: the API key to use when authenticating requests.
 * `address`: Base your URL of your Vieter instance, e.g. https://example.com
 
-### Cron
+### `vieter repos`
 
-* `log_level`: defines how much logs to show. Valid values are one of `FATAL`,
-  `ERROR`, `WARN`, `INFO` or `DEBUG`. Defaults to `WARN`
 * `api_key`: the API key to use when authenticating requests.
-* `address`: Base your URL of your Vieter instance, e.g. https://example.com.
+* `address`: Base your URL of your Vieter instance, e.g. https://example.com
-  This *must* be the publicly facing URL of your Vieter instance.
+* `base_image`: image to use when building a package using `vieter repos
-* `data_dir`: where Vieter stores the log file.
+  build`.
-* `base_image`: Docker image from which to create the builder images.
+    * Default: `archlinux:base-devel`
-* `max_concurrent_builds`: amount of builds to run at once.
+
-* `api_update_frequency`: how frequenty to check for changes in the repo list.
-* `image_rebuild+frequency`: how frequently to rebuild the builder image
-* `global_schedule`: cron schedule to use for any repo without an individual
-  schedule

docs/content/usage/builds/_index.md

@@ -38,3 +38,14 @@ The above command intentionally leaves out a few parameters to make the CLI
 more useable. For information on how to modify all parameters using the CLI,
 see
 [vieter-repos-edit(1)](https://rustybever.be/man/vieter/vieter-repos-edit.1.html).
+
+## Reading logs
+
+The logs of each build are uploaded to the Vieter repository server, along with
+information about the exit code of the build container, when the build
+started/ended etc. These logs can then be accessed using the [HTTP
+API](https://rustybever.be/docs/vieter/api/).
+
+For ease of use, the logs are also available using some CLI commands; see
+[vieter-logs(1)](https://rustybever.be/man/vieter/vieter-logs.1.html) for more
+information.

docs/content/usage/usage.md

@@ -1,54 +0,0 @@
----
-weight: 30
----
-# Usage
-
-## Starting the server
-
-To start a server, either install it using Docker (see
-[Installation](/installation)) or run it locally by executing `vieter
-server`. See [Configuration](/configuration) for more information about
-configuring the binary.
-
-## Multiple repositories
-
-Vieter works with multiple repositories. This means that a single Vieter server
-can serve multiple repositories in Pacman. It also automatically divides files
-with specific architectures among arch-repos. Arch-repos are the actual
-repositories you add to your `/etc/pacman.conf` file. See [Configuring
-Pacman](/usage#configuring-pacman) below for more info.
-
-## Adding packages
-
-Using Vieter is currently very simple. If you wish to add a package to Vieter,
-build it using makepkg & POST that file to the `/<repo>/publish` endpoint of
-your server. This will add the package to the repository. Authentification
-requires you to add the API key as the `X-Api-Key` header.
-
-All of this can be combined into a simple cURL call:
-
-```
-curl -XPOST -H "X-API-KEY: your-key" -T some-package.pkg.tar.zst https://example.com/somerepo/publish
-```
-
-`somerepo` is automatically created if it doesn't exist yet.
-
-## Configuring Pacman
-
-Configuring Pacman to use a Vieter instance is very simple. In your
-`/etc/pacman.conf` file, add the following lines:
-
-```
-[vieter]
-Server = https://example.com/$repo/$arch
-SigLevel = Optional
-```
-
-Here, you see two important placeholder variables. `$repo` is replaced by the
-name within the square brackets, which in this case would be `vieter`. `$arch`
-is replaced by the output of `uname -m`. Because Vieter supports multiple
-repositories & architectures per repository, using this notation makes sure you
-always use the correct endpoint for fetching files.
-
-I recommend placing this below all other repository entries, as the order
-decides which repository should be used if there's ever a naming conflict.