archlinux/infrastructure!617

It is unlikely a "signing enclave"[1] will be implemented in the short
term, and rather than wait forever, we can sign with a GPG key until a
better solution present itself. The GPG master-key is stored in the
infrastructure repository[2].

[1] infrastructure#280
[2] infrastructure!579

Fix #132

It is a bit odd to use git tags for every release, when the code isn't
changing, it is just newer packages. Using GitLab's package registry[1],
means new releases can be uploaded without messing with git tags and it
is also a bit easier to purge old releases, which is needed to keep the
storage under control.

Old releases are purged after 90 days, which match the number of days
the releases are kept on the mirrors (6 releases are kept on the mirrors
and we are releasing biweekly).

[1] https://docs.gitlab.com/ee/user/packages/generic_packages/

Fix #118

Fixes: 3bda5b26 ("Use new experimental VM runners[1] for building")

A VM with KVM acceleration is much faster than TCG, and the current
setup somehow broke again :/

[1] archlinux/infrastructure!385

The jobs will get stuck as the secure runner is only enabled for the
archlinux group.

The fast-single-thread runner is much faster (test-cloudimg-qemu):
3min 39sec[1] vs 8min 37sec[2]

[1] https://gitlab.archlinux.org/klausenbusk/arch-boxes/-/jobs/14739
[2] https://gitlab.archlinux.org/klausenbusk/arch-boxes/-/jobs/14746

It is similar to the cloud-image but it comes with a preconfigured arch
user (pw: arch) and lacks cloud-init.

Some of our runners is vey slow and building on them takes +1 hour and
we need to adjust many of the timeouts, so let's just build on the fast
runners.

http/install-common.sh:
Order pacman-init.service and reflector-init.service before
cloud-final.service, as the latter may install packages using pacman and
will introduce a broken pacman keyring if started simultaneously with
pacman-init.service.
The mirrorlist should be set before cloud-final.service is running, so
that pacman can use it.

.gitlab-ci.yml:
When testing the cloud image using cloud-init:
* Use the `packages` and `runcmd` directives to install packages using
  cloud-init (which is done during `cloud-final.service`).
* Check for packages installed via cloud-init.
* Write a test file to disk and check for its existence.

Fixes #121

This is helpful for checking out the results of merge requests, for instance.

This will allow us to make multiple releases a day which would be nice for hotfixes and such.

This will allow us to link a release to a file to specific Vagrant Cloud version.

See also https://docs.gitlab.com/ee/ci/metrics_reports.html

Our security concept doesn't allow us to move artifacts built in non-secure environments to secure environments.
This means we'll have to make sure that the boxes we release are built on a runner marked as
'secure'.

Using actual VMs to build VMs is slow and error-prone (you need to use
VNC to see what is going on, and booting takes over +110 seconds as we
wait to be sure Arch Linux is ready).

build.sh can build all three images in ~135 seconds (assuming all the
packages is cached), we still need to use a VM for the actually building
in GitLab CI (as that is the only safe way it can be done at the
moment), which is a bit slower (~22 min vs ~13 min (Packer)), but that
isn't really a big issue.

In the future we can hopefully switch to Kate Containers[1] and reduce
the build time significantly.

[1] infrastructure#108

Kristian Klausen authored 4 years ago and Sven-Hendrik Haase committed 4 years ago

Fix #108