Closing the Automated Continuous Integration Loop

Background The last phase in the current CI workflow is running the LAVA automated tests, and there is no mechanism in place to properly process and report these tests results which basically leave the CI loop incomplete. Current Issues The biggest issues are: Tests results need to be checked manually from LAVA logs and dashboard. Bugs need to be reported manually for tests issues. Weekly test reports need to be created manually. [Read More]

Jenkins and Docker

Jenkins and Docker This document provides a high-level overview of the reasons to adopt Docker for the Jenkins jobs used by the Apertis infrastructure and covers the steps needed to transition existing non-Docker jobs. What is Jenkins Jenkins is the automation server that ties all the components of the Apertis infrastructure together. It is responsible for: building source packages from git repositories and submitting them to OBS building ospacks and images submitting test jobs to LAVA rendering documentation from Markdown to HTML and PDF and publishing it building sample app-bundles bundling test helpers What is Docker Docker is the leading system to build, manage and run server applications in a containerized environment. [Read More]

License validation

License validation Scope The scope of this document is to describe a suitable system to deal with license requirements and compliance validation. Terminology and concepts Agent Software component responsible for the extraction of licensing information from source packages Copyright Legal right created by the law of a country that grants the creator of an original work exclusive rights for its use and distribution License Legal instrument (usually by way of contract law, with or without printed material) governing the use or redistribution of software [Read More]

Maintaining workspace across SDK updates

Background The SDK is distributed as a VirtualBox image, and developers make changes to adjust the SDK to their needs. These changes include installing tools, libraries, changing system configuration files, and adding content to their workspace. There is one VirtualBox image for each version of the SDK, and currently a version upgrade requires each developer to manually migrate their SDK customization to the new version. This migration is time consuming, and involves frustrating and repetitive work. [Read More]

Release artifacts for Apertis v2019 [draft]

Introduction This draft document describes which artifacts are expected to be part of the Apertis v2019 release and what are their goals. The main kinds of artifacts are: ospack: rootfs without the basic hardware-specific components like bootloader, kernel and hardware-specific support libraries system image: combines an ospack with hardware-specific components in a snapshot that can be directly deployed on the supported boards Apt-based images: images meant for development, with a modifiable rootfs that can be customized with the Apt package manager OSTree-based images: images with a immutable rootfs and a reliable update mechanism based on OSTree, more similar to what products would use than the Apt-based images OSTree repository: server backend used by the OSTree-based images for efficient distribution of updates sysroot: rootfs to be used for cross-compilation for platform and application development targeting a specific image devroot: rootfs for targeting foreign platforms using binary emulation for platform and application development nfs: kernel, initrd, dtb and rootfs tarball for network booting using TFTP and NFS Supported platforms Architectures: [Read More]

Test case dependencies on immutable rootfs

Test case dependencies on immutable rootfs Overview Immutable root filesystems have several security and maintainability advantages, and avoiding changes to them increases the value of testing as the system under test would closely match the production setup. This is fundamental for setups that don't have the ability to install packages at runtime, like OSTree-based deployments, but it's largely beneficial for package based setups as well. To achieve that, tests should then ship their own dependencies in a self-contained way and not rely on package installation at runtime. [Read More]

Test Data Reporting

Background Testing is a fundamental part of the project, but it is not so useful unless it goes along with an accurate and convenient model to report the results of such a testing. Receiving notifications on time about critical issues, easily checking tests results, or analyzing tests trends among different images versions are some of the examples of test reporting that helps to keep a project in a good state through its different phases of development. [Read More]

Test Data Storage

Background Testing is a core part of the project, and different test data is required to optimise the testing process. Currently the project does not have a functional and well defined place for storage of the different types of test data, which creates many issues across the testing processes. The goal of this document is to define a single storage place for all the test data and build on top it the foundation for accurate test data processing and reporting. [Read More]

Build infrastructure on Intel x86-64

Build infrastructure on Intel x86-64 Introduction The current Apertis infrastructure is largely made of hosts based on the Intel x86-64 architecture, often using virtualized machines. The only exceptions are: OBS workers used to build packages natively for the ARM 32 bit and ARM 64 bit architectures LAVA workers, which match the reference hardware platforms While LAVA workers are by nature meant to be hosted separatedly from the rest of the infrastructure and are handled via geographically distributed LAVA dispatchers, the constraint on the OBS workers is problematic for adopters that want to host a downstream Apertis infrastructure. [Read More]

Release flow and product lines

Introduction Apertis and its direct downstreams are intended as baseline distributions for further product development, as such it's important to have a clear definition of what downstreams further down the chain can expect in terms of releases and support cycles in order to understand how to best use them in their product development cycles. The release cycles of Apertis and its direct downstreams are split up in two big phases: a development phase, containing various development releases followed by a product phase which contains various stable point releases. [Read More]