gparted/.gitlab-ci.yml

67 lines
2.0 KiB
YAML
Raw Normal View History

stages:
- build
- test
.centos_image_template: &centos_image_definition
# Use official CentOS image https://hub.docker.com/_/centos/.
image: centos:centos7
before_script:
- yum update -y
- yum install -y which gnome-common yelp-tools glib2-devel intltool
gcc-c++ libuuid-devel parted-devel gtkmm30-devel make
polkit file
Add initial create ext2 only FileSystem interface class test (!49) This is the first step of adding testing of the derived FileSystem interface classes which call the file system specific executables. Rather than mocking command execution and returned output the tests run the real commands, effectively making this integration testing. Test case setup determines the file system supported actions using get_filesystem_support() and individual tests are skipped if a feature is not supported, just as GParted does for it's actions. Each test creates it's own sparse image file and a fresh file system, performs a test on one FileSystem interface call and deletes the image file. This makes each test independent and allows them to run as a non-root user, provided the file system command itself doesn't require root. Errors reported for a failed interface call will include the GParted OperationDetails, which in turn includes the file system specific command used and stdout and stderr from it's execution. For example, temporarily breaking the test code to create a 10 KiB image file instead of 256 MiB one produces this: $ ./test_ext2 Running main() from test_ext2.cc [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from ext2Test [ RUN ] ext2Test.Create test_ext2.cc:199: Failure Value of: s_ext2_obj->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: <b><i>mkfs.ext2 -F -L &apos;&apos; &apos;/home/centos/programming/c/gparted/tests/test_ext2.img&apos;</i></b> 00:00:00 (ERROR) <i></i> <i>mke2fs 1.42.9 (28-Dec-2013) /home/centos/programming/c/gparted/tests/test_ext2.img: Not enough space to build proposed filesystem while setting up superblock </i> [ FAILED ] ext2Test.Create (25 ms) [----------] 1 test from ext2Test (25 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (30 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ext2Test.Create 1 FAILED TEST $ echo $? 1 Also as Utils:: and FileSystem::execute_command() are needed, this requires linking with GParted_Core for GParted_Core::mainthread and therefore with most of the non-UI classes in gpartedbin. Closes !49 - Add file system interface tests
2019-07-17 06:08:08 -06:00
# Extra packages only needed during the test stage.
Run test program under xvfb-run to satisfy need for an X11 display (!49) Running test_ext2 in GitLab Continuous Integration environment fails like this: (test_ext2:6338): Gtk-WARNING **: 09:06:17.576: cannot open display: Running main() from test_ext2.cc Obviously the GitLab CI environment doesn't have an X11 display, but unfortunately this test case code requires one. Utils::execute_command() calls Gtk::Main::run() so requires a Gtk::Main object constructing and therefore an X11 display, even though this program never displays anything graphical. The call chain is: main() test_ext2.cc Gtk::Main::Main() gtkmm/gtk/src/main.ccg Gtk::Main::init() [1] gtk_init() gtk/gtk/gtkmain.c [2] which exits with a non-zero exit status when the DISPLAY environment variable is unset. Looked at deriving from Gtk::Main class and writing a replacement init() method which calls gtk_init_check() instead of gtk_init() but Gtk::Main::instance_ is a private member so not accessible in a derived class. Tried using Glib::MainLoop instead of Gtk::Main, but that doesn't initialise everything that Gtk::Main(), so the program crashes. Therefore use xvfb-run [3][4] to run this test program against a virtual X11 display when a real display isn't available. Coded execution of xvfb-run into this test program so that it can simply be executed on the command line like the other test programs, without having to remember to run "xvfb-run ./test_ext2 ...". [1] Gtk::Main::init() https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.1/gtk/src/main.ccg#L287 [2] gtk_init() https://gitlab.gnome.org/GNOME/gtk/blob/3.10.9/gtk/gtkmain.c#L1000 [3] how to run gtk app on linux without an x server https://superuser.com/questions/624918/how-to-run-gtk-app-on-linux-without-an-x-server [4] Using GTK without DISPLAY https://stackoverflow.com/questions/11694278/using-gtk-without-display Closes !49 - Add file system interface tests
2019-09-24 02:17:30 -06:00
- yum install -y e2fsprogs xorg-x11-server-Xvfb
- cat /etc/os-release
.ubuntu_image_template: &ubuntu_image_definition
# Use official Ubuntu image https://hub.docker.com/_/ubuntu/.
image: ubuntu:latest
before_script:
- apt-get update
- apt-get install -y gnome-common yelp-tools libglib2.0-dev-bin
uuid-dev libparted-dev libgtkmm-3.0-dev make
policykit-1
Add initial create ext2 only FileSystem interface class test (!49) This is the first step of adding testing of the derived FileSystem interface classes which call the file system specific executables. Rather than mocking command execution and returned output the tests run the real commands, effectively making this integration testing. Test case setup determines the file system supported actions using get_filesystem_support() and individual tests are skipped if a feature is not supported, just as GParted does for it's actions. Each test creates it's own sparse image file and a fresh file system, performs a test on one FileSystem interface call and deletes the image file. This makes each test independent and allows them to run as a non-root user, provided the file system command itself doesn't require root. Errors reported for a failed interface call will include the GParted OperationDetails, which in turn includes the file system specific command used and stdout and stderr from it's execution. For example, temporarily breaking the test code to create a 10 KiB image file instead of 256 MiB one produces this: $ ./test_ext2 Running main() from test_ext2.cc [==========] Running 1 test from 1 test case. [----------] Global test environment set-up. [----------] 1 test from ext2Test [ RUN ] ext2Test.Create test_ext2.cc:199: Failure Value of: s_ext2_obj->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: <b><i>mkfs.ext2 -F -L &apos;&apos; &apos;/home/centos/programming/c/gparted/tests/test_ext2.img&apos;</i></b> 00:00:00 (ERROR) <i></i> <i>mke2fs 1.42.9 (28-Dec-2013) /home/centos/programming/c/gparted/tests/test_ext2.img: Not enough space to build proposed filesystem while setting up superblock </i> [ FAILED ] ext2Test.Create (25 ms) [----------] 1 test from ext2Test (25 ms total) [----------] Global test environment tear-down [==========] 1 test from 1 test case ran. (30 ms total) [ PASSED ] 0 tests. [ FAILED ] 1 test, listed below: [ FAILED ] ext2Test.Create 1 FAILED TEST $ echo $? 1 Also as Utils:: and FileSystem::execute_command() are needed, this requires linking with GParted_Core for GParted_Core::mainthread and therefore with most of the non-UI classes in gpartedbin. Closes !49 - Add file system interface tests
2019-07-17 06:08:08 -06:00
# Extra packages only needed during the test stage.
Run test program under xvfb-run to satisfy need for an X11 display (!49) Running test_ext2 in GitLab Continuous Integration environment fails like this: (test_ext2:6338): Gtk-WARNING **: 09:06:17.576: cannot open display: Running main() from test_ext2.cc Obviously the GitLab CI environment doesn't have an X11 display, but unfortunately this test case code requires one. Utils::execute_command() calls Gtk::Main::run() so requires a Gtk::Main object constructing and therefore an X11 display, even though this program never displays anything graphical. The call chain is: main() test_ext2.cc Gtk::Main::Main() gtkmm/gtk/src/main.ccg Gtk::Main::init() [1] gtk_init() gtk/gtk/gtkmain.c [2] which exits with a non-zero exit status when the DISPLAY environment variable is unset. Looked at deriving from Gtk::Main class and writing a replacement init() method which calls gtk_init_check() instead of gtk_init() but Gtk::Main::instance_ is a private member so not accessible in a derived class. Tried using Glib::MainLoop instead of Gtk::Main, but that doesn't initialise everything that Gtk::Main(), so the program crashes. Therefore use xvfb-run [3][4] to run this test program against a virtual X11 display when a real display isn't available. Coded execution of xvfb-run into this test program so that it can simply be executed on the command line like the other test programs, without having to remember to run "xvfb-run ./test_ext2 ...". [1] Gtk::Main::init() https://gitlab.gnome.org/GNOME/gtkmm/blob/3.10.1/gtk/src/main.ccg#L287 [2] gtk_init() https://gitlab.gnome.org/GNOME/gtk/blob/3.10.9/gtk/gtkmain.c#L1000 [3] how to run gtk app on linux without an x server https://superuser.com/questions/624918/how-to-run-gtk-app-on-linux-without-an-x-server [4] Using GTK without DISPLAY https://stackoverflow.com/questions/11694278/using-gtk-without-display Closes !49 - Add file system interface tests
2019-09-24 02:17:30 -06:00
- apt-get install -y e2fsprogs xvfb
- cat /etc/os-release
.build_stage_template: &build_stage_definition
stage: build
script:
- ./autogen.sh
- nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1
- echo nproc=$nproc
- make -j $nproc
- make install
.test_stage_template: &test_stage_definition
stage: test
script:
- ./autogen.sh
- nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1
- echo nproc=$nproc
- make -j $nproc
Exclude unit test which fails in Docker CI image (!4) Fragment of the tests/test-suite.log from the Docker CI image showing details of the unit test failure: Running main() from gtest_main.cc [==========] Running 26 tests from 1 test case. [----------] Global test environment set-up. [----------] 26 tests from BlockSpecialTest ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches test_BlockSpecial.cc:137: Failure Failed get_link_name(): Failed to open directory '/dev/disk/by-id' test_BlockSpecial.cc:168: Failure Failed follow_link_name(): Failed to resolve symbolic link '' test_BlockSpecial.cc:255: Failure Expected: (lnk.m_name.c_str()) != (bs.m_name.c_str()), actual: "" vs "" [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches (0 ms) ... [==========] 26 tests from 1 test case ran. (1 ms total) [ PASSED ] 25 tests. [ FAILED ] 1 test, listed below: [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches 1 FAILED TEST So the code is trying to find a symbolic link to a block device to use in the test. It is trying to read the directory /dev/disk/by-id to find a symbolic link, but the directory doesn't exist in the Docker CI image. The used directory was recently changed [1] to use one which existed on all distributions. Docker images don't even have the /dev/disk directory. Exclude just this specific test. [1] 7fe41480749c795dfb79daeba7b058cece2dfdd2 Use /dev/disk/by-id/ to get device symlink in test_BlockSpecial Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 08:27:29 -06:00
# Exclude specific unit test which fails without /dev/disk in Docker images.
- export GTEST_FILTER='-BlockSpecialTest.NamedBlockSpecialObjectBySymlinkMatches'
- make check
- make distcheck
# Check GParted can be built and installed on CentOS and Ubuntu.
centos_build:
<<: *centos_image_definition
<<: *build_stage_definition
ubuntu_build:
<<: *ubuntu_image_definition
<<: *build_stage_definition
# Check GParted unit tests and distcheck pass on CentOS and Ubuntu.
centos_test:
<<: *centos_image_definition
<<: *test_stage_definition
ubuntu_test:
<<: *ubuntu_image_definition
<<: *test_stage_definition