| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
do_fetch_containers runs as a postfunc of do_fetch and needs skopeo
from the native sysroot. However, DEPENDS only gates
do_prepare_recipe_sysroot which runs after do_fetch, so with a clean
tmp/ directory skopeo-native may not be built when do_fetch runs.
Add an explicit do_fetch[depends] on skopeo-native:do_populate_sysroot
when remote containers are configured so the ordering is correct.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
yocto-check-layer reports an error for any task between do_fetch and
do_build that has network enabled. Two changes fix this:
container-bundle.bbclass: Move do_fetch_containers from a standalone
task into a do_fetch postfunc. When remote containers are configured,
the anonymous function adds extend_recipe_sysroot as a do_fetch
prefunc (so skopeo-native is available) and do_fetch_containers as a
postfunc. Network access during do_fetch is permitted by the QA check.
container-registry-index: Remove do_container_registry_index from the
build dependency chain (drop "before do_build"). Registry push is a
deployment action requiring explicit invocation:
bitbake container-registry-index -c container_registry_index
The default do_build task now prints usage instructions.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix yocto-check-layer failure:
ERROR: Multiconfig dependency mc::vruntime-x86-64:vpdmn-initramfs-create:do_deploy
depends on nonexistent multiconfig configuration named configuration vruntime-x86-64
Several recipes and classes declared static mcdepends referencing
vruntime-aarch64 and vruntime-x86-64 multiconfigs. When parsed without
BBMULTICONFIG set (e.g. yocto-check-layer), BitBake validates these and
fails because the referenced multiconfigs don't exist.
Move mcdepends into anonymous python functions and only set them when
the target multiconfig exists in BBMULTICONFIG, following the pattern
established in meta/classes-recipe/kernel-fit-image.bbclass.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add support for custom systemd service files (Docker) or Quadlet
container files (Podman) instead of auto-generated ones for container
autostart.
For containers requiring specific startup configuration (ports, volumes,
capabilities, dependencies), users can now provide custom service files
using the CONTAINER_SERVICE_FILE varflag:
CONTAINER_SERVICE_FILE[container-name] = "${UNPACKDIR}/myservice.service"
For BUNDLED_CONTAINERS in image recipes:
SRC_URI += "file://myapp.service"
BUNDLED_CONTAINERS = "myapp-container:docker:autostart"
CONTAINER_SERVICE_FILE[myapp-container] = "${UNPACKDIR}/myapp.service"
For container-bundle packages:
SRC_URI = "file://myapp.service"
CONTAINER_BUNDLES = "myapp-container:autostart"
CONTAINER_SERVICE_FILE[myapp-container] = "${UNPACKDIR}/myapp.service"
Implementation:
- container-cross-install.bbclass: Add get_container_service_file_map()
to build varflag map, install_custom_service() for BUNDLED_CONTAINERS,
and install_custom_service_from_bundle() for bundle packages
- container-bundle.bbclass: Install custom service files to
${datadir}/container-bundles/${runtime}/services/
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add CONTAINER_BUNDLE_DEPLOY variable to enable dual-use of container-bundle:
1. Target packages (existing): Creates installable packages for target
container storage (Docker/Podman)
2. Base layer source (new): When CONTAINER_BUNDLE_DEPLOY = "1", also
deploys the fetched OCI image to DEPLOY_DIR_IMAGE for use as a base
layer via OCI_BASE_IMAGE
This enables fetching external images (docker.io, quay.io) and using them
as base layers for Yocto-built container images.
Example usage:
# recipes-containers/oci-base-images/alpine-oci-base_3.19.bb
inherit container-bundle
CONTAINER_BUNDLES = "docker.io/library/alpine:3.19"
CONTAINER_DIGESTS[docker.io_library_alpine_3.19] = "sha256:..."
CONTAINER_BUNDLE_DEPLOY = "1"
# Then in your app container recipe:
OCI_BASE_IMAGE = "alpine-oci-base"
IMAGE_INSTALL = "myapp"
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
| |
Update references to reflect the current architecture:
- Change vdkr-native/vpdmn-native to vcontainer-native in comments
- Remove TestContainerCrossTools and TestContainerCrossInitramfs from README
- Fix build command: vdkr-native → vcontainer-tarball
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create container-common.bbclass with shared Python functions used by both
container-bundle.bbclass and container-cross-install.bbclass:
- get_vruntime_multiconfig(d): Maps TARGET_ARCH to multiconfig name
- get_vruntime_machine(d): Maps TARGET_ARCH to MACHINE for deploy path
- get_blob_arch(d): Maps TARGET_ARCH to blob directory name
This removes ~55 lines of duplicated code and ensures consistency between
the two bbclass files.
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|
|
|
This class creates installable packages that bundle pre-processed
container images. When installed via IMAGE_INSTALL, containers are
automatically merged into the target image's container storage.
Component relationships for bundling a local container:
1. Application Recipe (builds the software)
recipes-demo/myapp/myapp_1.0.bb
- Compiles application binaries
- Creates installable package (myapp)
2. Container Image Recipe (creates OCI image containing the app)
recipes-demo/images/myapp-container.bb
- inherit image image-oci
- IMAGE_INSTALL = "myapp"
- Produces: ${DEPLOY_DIR_IMAGE}/myapp-container-latest-oci/
3. Bundle Recipe (packages container images for deployment)
recipes-demo/bundles/my-bundle_1.0.bb
- inherit container-bundle
- CONTAINER_BUNDLES = "myapp-container:autostart"
- Creates installable package with OCI data
Flow: application recipe -> container image recipe -> bundle recipe
-> IMAGE_INSTALL in host image -> container deployed on target
Usage:
inherit container-bundle
CONTAINER_BUNDLES = "myapp-container:autostart redis-container"
CONTAINER_BUNDLES format: source[:autostart-policy]
- source: Container IMAGE recipe name or remote registry URL
- autostart-policy: Optional (autostart, always, unless-stopped, on-failure)
Features:
- Auto-generates dependencies on container image recipes (do_image_complete)
- Supports remote containers via skopeo (requires CONTAINER_DIGESTS)
- Runtime auto-detected from CONTAINER_PROFILE (docker/podman)
- Produces OCI directories and metadata for container-cross-install
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
|