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` | ||||
| 
 | ||||
| * `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` | ||||
|  |  | |||
|  | @ -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: | ||||
|  |  | |||
|  | @ -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 | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue