docs: removed another old file & read over some parts
ci/woodpecker/pr/docs Pipeline was successful Details
ci/woodpecker/pr/lint Pipeline was successful Details
ci/woodpecker/pr/build Pipeline was successful Details
ci/woodpecker/pr/man Pipeline was successful Details
ci/woodpecker/pr/docker Pipeline was successful Details
ci/woodpecker/pr/test Pipeline was successful Details

pull/233/head
Jef Roosens 2022-06-09 21:46:39 +02:00
parent c15f4a482f
commit ddccceb336
Signed by: Jef Roosens
GPG Key ID: B580B976584B5F30
4 changed files with 5 additions and 61 deletions

View File

@ -1,56 +0,0 @@
# Builder
Vieter supports a basic build system that allows you to build the packages
defined using the Git repositories API by running `vieter build`. For
configuration, see [here](/configuration#builder).
## How it works
The build system works in two stages. First it pulls down the
`archlinux:latest` image from Docker Hub, runs `pacman -Syu` & configures a
non-root build user. It then creates a new Docker image from this container.
This is to prevent each build having to fully update the container's
repositories. After the image has been created, each repository returned by
`/api/repos` is built sequentially by starting up a new container with the
previously created image as a base. Each container goes through the following steps:
1. The repository is cloned
2. `makepkg --nobuild --syncdeps --needed --noconfirm` is ran to update the `pkgver` variable inside
the `PKGBUILD` file
3. A HEAD request is sent to the Vieter server to check whether the specific
version of the package is already present. If it is, the container exits.
4. `makepkg` is ran with `MAKEFLAGS="-j\$(nproc)`
5. Each produced package archive is uploaded to the Vieter instance's
repository, as defined in the API for that specific Git repo.
## Cron image
The Vieter Docker image contains crond & a cron config that runs `vieter build`
every night at 3AM. This value is currently hardcoded, but I wish to change
that down the line (work is in progress). There's also some other caveats you
should be aware of, namely that the image should be run as root & that the
healthcheck will always fail, so you might have to disable it. This boils down
to the following docker-compose file:
```yaml
version: '3'
services:
cron:
image: 'chewingbever/vieter:dev'
command: crond -f
user: root
healthcheck:
disable: true
environment:
- 'VIETER_API_KEY=some-key'
- 'VIETER_ADDRESS=https://example.com'
volumes:
- '/var/run/docker.sock:/var/run/docker.sock'
```
Important to note is that the container also requires the host's Docker socket
to be mounted as this is how it spawns the necessary containers, as well as a
change to the container's command.

View File

@ -86,12 +86,12 @@ configuration variable required for each command.
### `vieter logs`
* `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 URL of your Vieter instance, e.g. https://example.com
### `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
* `address`: Base 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`

View File

@ -20,8 +20,8 @@ The latter is updated every time a new commit is pushed to the development
branch. This branch will be the most up to date, but does not give any
guarantees about stability, so beware!
Due to the single-binary design of Vieter, this image can be used both for the
repository server & the cron daemon.
Thanks to the single-binary design of Vieter, this image can be used both for
the repository server & the cron daemon.
Below is an example compose file to set up both the repository server & the
cron daemon:

View File

@ -78,4 +78,4 @@ This script:
3. Clones the Git repository
4. Runs `makepkg` without building to calculate `pkgver`
5. Checks whether the package version is already present on the server
6. If not, run makepkg & publish any generated package archives to the server
6. If not, run `makepkg` & publish any generated package archives to the server