docs: some changed; removed some old files

main
Jef Roosens 2022-06-09 17:24:16 +02:00 committed by Jef Roosens
parent a9ddfd8ec8
commit c341d7a024
Signed by untrusted user: Jef Roosens
GPG Key ID: B580B976584B5F30
5 changed files with 20 additions and 103 deletions

View File

@ -112,7 +112,7 @@ Parameter | Description
url | URL of the Git repository. url | URL of the Git repository.
branch | Branch of the Git repository. branch | Branch of the Git repository.
repo | Vieter repository to publish built packages to. 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. arch | Comma-separated list of architectures to build package on.
## Modify a repo ## Modify a repo

View File

@ -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.

View File

@ -47,14 +47,6 @@ configuration variable required for each command.
* Git repositories added without an `arch` value use this value instead. * 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` ### `vieter cron`
* `log_level`: log verbosity level. Value should be one of `FATAL`, `ERROR`, * `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. how frequently (in minutes) to rebuild this builder image.
* Default: `1440` (every 24 hours) * Default: `1440` (every 24 hours)
* `global_schedule`: build schedule for any Git repository that does not have a * `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) * Default: `0 3` (3AM every night)
### `vieter logs` ### `vieter logs`
@ -95,17 +88,11 @@ configuration variable required for each command.
* `api_key`: the API key to use when authenticating requests. * `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
### 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. * `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

View File

@ -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, more useable. For information on how to modify all parameters using the CLI,
see see
[vieter-repos-edit(1)](https://rustybever.be/man/vieter/vieter-repos-edit.1.html). [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.

View File

@ -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.