docs: some changed; removed some old files
parent
d010aa10c4
commit
f0f74e2428
|
@ -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
|
||||||
|
|
|
@ -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.
|
|
|
@ -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
|
|
||||||
|
|
|
@ -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.
|
||||||
|
|
|
@ -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.
|
|
Loading…
Reference in New Issue