forked from vieter-v/vieter
docs: removed another old file & read over some parts
parent
c15f4a482f
commit
ddccceb336
|
@ -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.
|
|
|
@ -86,12 +86,12 @@ configuration variable required for each command.
|
||||||
### `vieter logs`
|
### `vieter logs`
|
||||||
|
|
||||||
* `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 URL of your Vieter instance, e.g. https://example.com
|
||||||
|
|
||||||
### `vieter repos`
|
### `vieter repos`
|
||||||
|
|
||||||
* `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 URL of your Vieter instance, e.g. https://example.com
|
||||||
* `base_image`: image to use when building a package using `vieter repos
|
* `base_image`: image to use when building a package using `vieter repos
|
||||||
build`.
|
build`.
|
||||||
* Default: `archlinux:base-devel`
|
* Default: `archlinux:base-devel`
|
||||||
|
|
|
@ -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
|
branch. This branch will be the most up to date, but does not give any
|
||||||
guarantees about stability, so beware!
|
guarantees about stability, so beware!
|
||||||
|
|
||||||
Due to the single-binary design of Vieter, this image can be used both for the
|
Thanks to the single-binary design of Vieter, this image can be used both for
|
||||||
repository server & the cron daemon.
|
the repository server & the cron daemon.
|
||||||
|
|
||||||
Below is an example compose file to set up both the repository server & the
|
Below is an example compose file to set up both the repository server & the
|
||||||
cron daemon:
|
cron daemon:
|
||||||
|
|
|
@ -78,4 +78,4 @@ This script:
|
||||||
3. Clones the Git repository
|
3. Clones the Git repository
|
||||||
4. Runs `makepkg` without building to calculate `pkgver`
|
4. Runs `makepkg` without building to calculate `pkgver`
|
||||||
5. Checks whether the package version is already present on the server
|
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
|
||||||
|
|
Loading…
Reference in New Issue