Files
kata-containers/tools/packaging
Greg Kurz afbd60da27 packaging: Fix clh build from source fall-back
If we fail to download the clh binary, we fall-back to build from source.
Unfortunately, `pull_clh_released_binary()` leaves a `cloud_hypervisor`
directory behind, which causes `build_clh_from_source()` not to clone
the git repo:

    [ -d "${repo_dir}" ] || git clone "${cloud_hypervisor_repo}"

When building from a kata-containers git repo, the subsequent calls
to `git` in this function thus apply to the kata-containers repo and
eventually fail, e.g.:

+ git checkout v23.0
error: pathspec 'v23.0' did not match any file(s) known to git

It doesn't quite make sense actually to keep an existing directory the
content of which is arbitrary when we want to it to contain a specific
version of clh. Just remove it instead.

Fixes: #4151

Signed-off-by: Greg Kurz <groug@kaod.org>
2022-04-26 17:57:32 +02:00
..
2022-03-16 10:35:39 -06:00
2022-03-16 10:35:39 -06:00
2022-01-20 18:00:58 +00:00
2022-01-20 18:00:58 +00:00

Kata Containers packaging

Introduction

Kata Containers currently supports packages for many distributions. Tooling to aid in creating these packages are contained within this repository.

Build in a container

Kata build artifacts are available within a container image, created by a Dockerfile. Reference DaemonSets are provided in kata-deploy, which make installation of Kata Containers in a running Kubernetes Cluster very straightforward.

Build a snap package

See the snap documentation.

Build static binaries

See the static build documentation.

Build Kata Containers Kernel

See the kernel documentation.

Build QEMU

See the QEMU documentation.

Create a Kata Containers release

See the release documentation.

Packaging scripts

See the scripts documentation.

Credits

Kata Containers packaging uses packagecloud for package hosting.