fwupd/contrib/ci
2022-09-23 16:39:21 +01:00
..
out-of-tree-link trivial: Make meson.build indentation consistent 2022-06-21 03:27:38 -04:00
qt5-thread-test trivial: Make meson.build indentation consistent 2022-06-21 03:27:38 -04:00
abidiff.suppr Allow the daemon to request interactive action from the end user 2021-07-14 17:03:50 +01:00
arch.sh contrib/ci: do not upgrade Arch continuously 2022-07-23 09:49:55 -05:00
build_freebsd_package.sh build_freebsd_package.sh: Build package with generated pkg-plist 2021-08-18 08:39:11 -05:00
build_macos.sh Convert HSI into a meson tristate-feature 2022-08-22 06:03:38 -05:00
build_windows.sh trivial: windows: Install windows service 2022-08-30 12:06:16 -05:00
centos.sh trivial: change docs to a meson feature (Fixes: #4791) 2022-07-01 10:56:12 +01:00
check_missing_translations.sh Catch missing translation files in POTFILES.in 2018-06-29 06:43:06 +01:00
check-abi trivial: change docs to a meson feature (Fixes: #4791) 2022-07-01 10:56:12 +01:00
check-deprecated.sh trivial: Add pre-commit hooks for style 2021-04-09 16:02:20 +01:00
check-finalizers.py Add a precommit script to check for missing GObject finalizers 2022-07-11 11:16:47 +01:00
check-headers.py Move the getting the ESP to the context 2022-09-22 14:31:06 +01:00
check-license.py trivial: don't run check-license on headers in dist/ 2022-05-10 18:57:17 +01:00
check-null-false-returns.py trivial: don't check for null/false returns on dist or subprojects 2022-05-10 18:57:17 +01:00
check-potfiles.py Add support for translation for the sample Dell BIOS setting strings 2022-08-10 10:17:25 -05:00
check-quirks.py trivial: Make the quirk style more consistent 2021-08-23 18:10:12 +01:00
debian_s390x.sh trivial: change docs to a meson feature (Fixes: #4791) 2022-07-01 10:56:12 +01:00
debian.sh trivial: Fix Debian CI harder 2022-09-06 18:46:14 +01:00
dependencies.xml trivial: add libumock-dev into debian/control 2022-09-07 08:33:02 -05:00
Dockerfile-arch.in trivial: arch: generate locales in the container 2022-06-27 00:26:47 -05:00
Dockerfile-debian.in trivial: ci: debian: Use helper script to install dependencies instead. (#4906) 2022-08-05 08:43:13 +01:00
Dockerfile-fedora.in trivial: Fix Fedora CI 2022-04-22 11:58:05 +01:00
Dockerfile-snap.in trivial: snap: pull from edge channel to build 2019-02-25 21:27:18 -06:00
Dockerfile-ubuntu.in Revert "trivial: move some jobs back to Ubuntu 20.04 to fix CI" 2022-06-28 08:29:16 -05:00
Dockerfile-void.in trivial: fix void docker container creation 2021-07-28 21:42:54 -05:00
fedora.sh Use -Db_sanitize=address,undefined in Fedora CI 2022-07-29 17:09:50 +01:00
flatpak.py Rename the development branch from master to main 2021-09-24 14:20:24 -05:00
fwupd_setup_helpers.py trivial: debian: don't populate dependencies without <control> 2022-09-07 08:33:02 -05:00
generate_debian.py trivial: debian: fix debian/control generator 2022-09-05 07:09:05 -05:00
generate_dependencies.py trivial: Merge python steps from contrib/setup into helper script 2021-09-17 10:59:35 -05:00
generate_docker.py trivial: fix container generation 2022-09-08 23:18:22 -05:00
generate_news.py trivial: don't use built-in types 2021-08-18 07:58:17 -05:00
get_test_firmware.sh Remove PLUGINBUILDDIR and use G_TEST_SRCDIR and G_TEST_BUILDDIR instead 2021-10-21 18:36:22 +01:00
oss-fuzz.py Add support for platform capability descriptors so devices can set quirks 2022-09-13 12:07:35 +01:00
populate-bios-setting-translations.py trivial: Unify ambiguity between bios-attrs and bios-settings 2022-08-24 07:20:01 -05:00
README.md trivial: Merge python steps from contrib/setup into helper script 2021-09-17 10:59:35 -05:00
s390x_cross.txt Introduce an s390x cross compile target to CI 2017-09-08 09:24:54 +01:00
snap.sh trivial: fix various shellcheck warnings 2021-08-18 07:58:17 -05:00
snapcraft-wrapper trivial: snap: pull from edge channel to build 2019-02-25 21:27:18 -06:00
ubuntu.sh trivial: Remove long-dead meson option 2022-09-23 16:39:21 +01:00
void.sh Convert build system to use meson tristate features 2022-02-28 08:34:48 -06:00

Continuous Integration

By using CI, builds are exercised across a variety of environments attempting to maximize code coverage. For every commit or pull request 6 builds are performed:

Fedora (x86_64)

  • A fully packaged RPM build with all plugins enabled
  • Compiled under gcc with AddressSanitizer
  • Tests with -Werror enabled
  • Tests with the built in local test suite for all plugins.
  • All packages are installed
  • An installed testing run with the "test" plugin and pulling from LVFS.
  • With modem manager disabled

Debian testing (x86_64)

  • A fully packaged DEB build with all plugins enabled
  • Compiled under gcc
  • Tests with -Werror enabled
  • Tests with the built in local test suite for all plugins.
  • All packages are installed
  • An installed testing run with the "test" plugin and pulling from LVFS.
  • All packages are removed

Debian testing (i386)

  • A fully packaged DEB build with all plugins enabled
  • Compiled under gcc
  • Tests with -Werror enabled
  • Tests with the built in local test suite for all plugins.
  • All packages are installed
  • An installed testing run with the "test" plugin and pulling from LVFS.
  • All packages are removed

Ubuntu devel release (x86_64)

  • A fully packaged DEB build with all plugins enabled
  • Compiled under clang
  • Tests without -Werror enabled
  • Tests with the built in local test suite for all plugins.
  • All packages are installed
  • An installed testing run with the "test" plugin and pulling from LVFS.
  • All packages are removed

Debian testing (cross compile s390x)

  • Not packaged
  • Tests for missing translation files
  • No redfish support
  • Compiled under gcc
  • Tests with -Werror enabled
  • Runs local test suite using qemu-user
  • Modem manager disabled

Arch Linux (x86_64)

  • A fully packaged pkg build with all plugins enabled
  • Compiled under gcc
  • Tests with -Werror enabled
  • Compile with the deprecated USB plugin enabled
  • Tests with the built in local test suite for all plugins.
  • All packages are installed

Flatpak

  • A flatpak bundle with all plugins enabled
  • Compiled under gcc with the org.gnome.Sdk/x86_64/3.28 runtime
  • Builds without the daemon, so only fwupdtool is available
  • No GPG, PKCS-7, GObjectIntrospection, systemd or ConsoleKit support
  • No tests

Adding a new target

Dockerfiles are generated dynamically by the python script generate_dockerfile.py. The python script will recognize the environment variable OS to determine what target to generate a Dockerfile for.

dependencies.xml

Initially the python script will read in dependencies.xml to generate a dependency list for that target. The XML is organized by a top level element representing the dependencies needed for building fwupd.

The child elements represent individual dependencies for all distributions.

  • This element has an attribute id that represents the most common package name used by distributions
  • This element has an attribute type that represents if the package is needed at build time or runtime.

Each dependency then has a mapping to individual distributions (distro).

  • This element has an attribute id that represents the distribution.

Each distribution will have package elements and control elements. Package elements represent the name of the package needed for the distribution.

  • An optional attribute variant represents one deviation of that distribution. For example building a specific architecture or with a different compiler.
  • If the package element is empty the id of the dependency element will be used.
  • Control elements represent specific requirements associated to a dependency. They will contain elements with individual details.
  • version elements represent a minimum version to be installed
  • inclusive elements represent an inclusive list of architectures to be installed on
  • exclusive elements represent an exclusive list of architectures to not be installed on

For convenience there is also a helper script ./contrib/ci/fwupd_setup_helpers.p install-dependencies that parses dependencies.xml.

Dockerfile.in

The Dockerfile.in file will be used as a template to build the container. No hardcoded dependencies should be put in this file. They should be stored in dependencies.xml.