fwupd/contrib/ci
Tomas Winkler 2a026147ce ci: allow working with podman w/o aliases
Fedora doesn't distribute docker anymore, instead
it uses podman for the containers.
It is possible to alias podman to docker, but
it's less hassle if it will work just out of the box.

The fix here is simple the podman is a fallback if
docker is not found.

Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
2020-01-29 08:43:31 +00:00
..
abidiff.suppr trivial: Add all the _LAST enums that shouldn't be checked for ABI 2019-11-01 08:16:18 -05:00
arch.sh trivial: arch: ci: Wait some time for tpm_server to start up 2019-10-15 09:10:15 -05:00
build_windows.sh Generate a win32 setup binary 2020-01-16 12:23:08 -06:00
centos.sh Disable the flashrom plugin by default 2019-07-15 10:37:34 -07:00
check_missing_translations.sh Catch missing translation files in POTFILES.in 2018-06-29 06:43:06 +01:00
check-abi Verify we don't break the ABI 2019-08-01 10:47:49 -05:00
debian_s390x.sh flashrom: Use libflashrom 2019-06-28 08:28:51 +01:00
debian.sh Revert "trivial: Attempt to fix Debian CI" 2020-01-08 21:08:59 +00:00
dependencies.xml Add a new plugin that exposes the system TPM device firmware version 2019-12-05 21:05:17 +00:00
Dockerfile-arch.in contrib: Don't declare OS variable in docker run command (Fixes: #413) 2018-02-21 13:30:12 -06:00
Dockerfile-centos.in Port from libappstream-glib to libxmlb 2018-10-17 14:41:13 +01:00
Dockerfile-debian.in Add a new plugin that exposes the system TPM device firmware version 2019-12-05 21:05:17 +00:00
Dockerfile-fedora.in Shut down automatically when there is system memory pressure 2020-01-07 12:29:07 +00:00
Dockerfile-flatpak.in trivial: Move Fedora CI to f29 2019-01-28 15:42:30 +00:00
Dockerfile-snap.in trivial: snap: pull from edge channel to build 2019-02-25 21:27:18 -06:00
Dockerfile-ubuntu.in ci: Run clang static analysis for Ubuntu build rather than just clang compiler 2018-09-21 07:35:08 +01:00
fedora.sh ci: fedora: force correct rpm package version 2020-01-29 08:22:41 +00:00
flatpak.py trivial: ci: Don't use strict when parsing json 2019-02-25 21:27:18 -06:00
generate_debian.py trivial: ci: don't let bad symlinks cause debian build failures 2019-11-30 18:43:24 -06:00
generate_docker.py ci: allow working with podman w/o aliases 2020-01-29 08:43:31 +00:00
README.md trivial: update references of hughsie/fwupd to fwupd/fwupd 2019-08-22 09:47:52 -05:00
s390x_cross.txt Introduce an s390x cross compile target to CI 2017-09-08 09:24:54 +01:00
snap.sh Add support for creating snaps 2018-05-31 14:12:06 -05:00
snapcraft-wrapper trivial: snap: pull from edge channel to build 2019-02-25 21:27:18 -06:00
ubuntu.sh trivial: Don't build the Ubuntu CI with Werror 2020-01-02 12:52:51 +00:00

Continuous Integration

Continuous integration for fwupd is provided by Travis CI.

By using Travis 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 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

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.