Verified Commit 30ee8afd authored by Sven-Hendrik Haase's avatar Sven-Hendrik Haase
Browse files

Update README for post-refactor

The README was basically entirely out of date.
parent 4b6b2675
Pipeline #1900 passed with stages
in 24 minutes and 55 seconds
......@@ -4,90 +4,29 @@
- [Vagrant Cloud](https://app.vagrantup.com/archlinux/boxes/archlinux)
- [Download latest qcow2 image](https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/artifacts/master/download?job=build:secure)
Arch-boxes provides automated builds of the Arch Linux releases for different providers and
post-processors. Check the providers or post-processor sections if you want to know which are
currently supported.
Arch-boxes provides automated builds of the Arch Linux releases for different providers and formats.
## Dependencies
You'll need the following dependencies:
* packer (for basic usage)
* vagrant (for vagrant images)
* qemu
## Variables
Here is an overview over all variables you can set in `config.json`:
* `iso_url`: the url to the ISO. This can be an url or a filepath
beginning with `file://`
* `iso_checksum_url`: the url to the checksum file. This can be an url
or a filepath beginning with `file://`
* `iso_checksum_type`: this specifies the hashing algorithm for the
checksum.
* `disk_size`: this specifices the disk size in bytes.
* `headless`: this sets GUI on or off.
* `boot_wait`: this specifies the time packer should wait for booting up
the ISO before entering any command.
## How to start the build process locally
If you want to build the boxes locally without uploading them to the Vagrant
cloud. You can start the build for virtualbox only with the following command:
`packer build -only=qemu config.json`
## How to start the build process for official builds
## How to build this
The official builds are done in our Arch Linux GitLab CI.
`packer build config.json`
## Providers
* virtualbox
* qemu/libvirt
## Post-processors
* vagrant (*.box)
* cloud (*.qcow2)
./build-host.sh
## Development workflow
Merge requests and general development shall be made on the `master` branch.
For security reasons, we're not allowing our CI runners on other branches than
`master` or `release` so MRs won't properly run their CI.
Therefore, the development flow is:
1. Make a MR against `master`.
2. After code review, a maintainer locally needs to build the changes.
3. The maintainer then needs to merge the changes to `master`.
We have CI in place to build all images even for merge requests.
## Release workflow
Releases are done automatically via [GitLab CI
schedule](https://gitlab.archlinux.org/archlinux/arch-boxes/-/pipeline_schedules).
Releases are done automatically via [GitLab CI schedule](https://gitlab.archlinux.org/archlinux/arch-boxes/-/pipeline_schedules).
No manual intervention is required or desired.
The release flow is:
1. A maintainer makes a MR from `master` against `release`.
2. The MR is merged on GitLab.
3. A release is done automatically and regularly from the `release` branch.
## Troubleshooting
### Parallel build fails
If the parallel build fails this is mostly because the KVM device is
already occupied by a different provider. You can use the build option
`parallel=false` for building the images in a queue instead of parallel.
But don't be surprised that that the build process will take longer. Any
other option is to disable KVM support for all other providers except
one.
Start `packer` with `-parallel=false`:
`packer build -parallel=false config.json`
### Checking cloud-init support in our qcow2 images:
## Checking cloud-init support in our qcow2 images:
```bash
$ packer build -only=cloud -except=sign config.json
$ cp Arch-Linux-cloudimg-2020-02-24.qcow2 disk.qcow2
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment