gparted/.gitlab-ci.yml

125 lines
4.1 KiB
YAML
Raw Permalink Normal View History

stages:
- build
- test
.alpine_image_template: &alpine_image_definition
# Use official Alpine image https://hub.docker.com/_/alpine/.
image: alpine:3.17
before_script:
- cat /proc/version
- cat /etc/os-release
- apk update
- apk add gnome-common yelp-tools automake autoconf glib-dev libtool g++
parted-dev gtkmm3-dev itstool make git polkit-dev
# Extra packages only needed during the test stage.
- apk add btrfs-progs btrfs-progs-extra e2fsprogs e2fsprogs-extra exfatprogs
dosfstools mtools f2fs-tools jfsutils cryptsetup lvm2 udftools
Speed up signature erasing unit test in Alpine Linux CI test job (#220) Each test in test_EraseFileSystemSignatures is taking just over 10 seconds to run in the Alpine Linux CI image: [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (10045 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned ... [ FAILED ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (10048 ms) [----------] 2 tests from EraseFileSystemSignaturesTest (20093 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (20093 ms total) This is because the udevadm command is not found and so settle_device() waits for 10 seconds in this call chain: erase_filesystem_signatures() settle_device(SETTLE_DEVICE_APPLY_MAX_WAIT_SECONDS) sleep(10) Install udevadm command into the Alpine Linux CI job docker image to fix this. Now it's on a par with the time taken in the other distro CI test jobs: [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned [ OK ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDAligned (417 ms) [ RUN ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned ... [ FAILED ] EraseFileSystemSignaturesTest.IntelSoftwareRAIDUnaligned (165 ms) [----------] 2 tests from EraseFileSystemSignaturesTest (582 ms total) [----------] Global test environment tear-down [==========] 2 tests from 1 test case ran. (582 ms total) Closes #220 - Format to Cleared not clearing "pdc" ataraid signature
2023-02-08 02:51:33 -07:00
xfsprogs xfsprogs-extra xvfb-run kmod gzip eudev
.centos_image_template: &centos_image_definition
# Use official CentOS image https://hub.docker.com/_/centos/.
image: centos:centos7
before_script:
- cat /proc/version
- cat /etc/os-release
- yum update -y
- yum install -y which gnome-common yelp-tools glib2-devel gcc-c++
libuuid-devel parted-devel gtkmm30-devel make polkit file
polkit-devel gettext-devel
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.
Extend tests to all fully supported file systems (!49) Extend testing to all fully supported file systems, those with an implemented FileSystem derived class. Note that in main() GParted threading needs to now be initialised before InitGoogleTest() because it calls INSTANTIATE_TEST_CASE_P() which in turn calls get_supported_fstypes() which eventually constructs all the individual file system interface objects and discovers available support, some of which use execute_command(). Example call chain: InitGoogleTest() INSTANTIATE_TEST_CASE_P() get_supported_fstypes() setup_supported_filesystems() {SupportedFileSystems}->find_supported_filesystems() {btrfs}->get_filesystem_support() Utils::execute_command() In the CentOS 7 GitLab CI image the EPEL (Extra Packages for Enterprise Linux) repository is added to provide f2fs-tools and ntfsprogs. 23 of 210 tests fail on CentOS 7 and 22 on Ubuntu 18.04 LTS. The following commits will resolve these test failures. $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc [==========] Running 210 tests from 1 test case. [----------] Global test environment set-up. [----------] 210 tests from My/SupportedFileSystemsTest ... [----------] 210 tests from My/SupportedFileSystemsTest (11066 ms total) [----------] Global test environment tear-down [==========] 210 tests from 1 test case ran. (11067 ms total) [ PASSED ] 187 tests. [ FAILED ] 23 tests, listed below: [ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/jfs, where GetParam() = 17 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/ntfs, where GetParam() = 23 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadLabel/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat16, where GetParam() = 13 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/fat32, where GetParam() = 14 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/jfs, where GetParam() = 17 [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUUID/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteLabel/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndWriteUUID/nilfs2, where GetParam() = 22 [ FAILED ] My/SupportedFileSystemsTest.CreateAndCheck/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndCheck/minix, where GetParam() = 21 [ FAILED ] My/SupportedFileSystemsTest.CreateAndRemove/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/lvm2pv, where GetParam() = 20 [ FAILED ] My/SupportedFileSystemsTest.CreateAndGrow/xfs, where GetParam() = 27 [ FAILED ] My/SupportedFileSystemsTest.CreateAndShrink/btrfs, where GetParam() = 7 [ FAILED ] My/SupportedFileSystemsTest.CreateAndShrink/lvm2pv, where GetParam() = 20 23 FAILED TESTS Closes !49 - Add file system interface tests
2019-08-05 09:13:04 -06:00
# Install EPEL repo first for f2fs-tools and ntfsprogs.
- yum install -y epel-release
- yum install -y btrfs-progs e2fsprogs exfatprogs f2fs-tools dosfstools
mtools hfsplus-tools util-linux cryptsetup device-mapper
lvm2 ntfsprogs udftools xfsprogs xfsdump
Prevent file system tests core dumping in GitLab CI Ubuntu image (!49) With the previous commit, execution of test_SupportedFileSystems is failing in the GitLab CI Ubuntu image. Fragment from file tests/test-suite.log: FAIL: test_SupportedFileSystems =============================== Terminate called after throwing an instance of 'Glib::ConvertError' Aborted (core dumped) FAIL test_SupportedFileSystems (exit status: 134) This core dump can be re-created locally by (1) removing modprobe from the PATH, and (2) executing the test program in the C locale. $ LC_ALL=C ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc terminate called after throwing an instance of 'Glib::ConvertError' Aborted $ echo $? 134 Backtrace from gdb: (gdb) backtrace #0 0x00007f4f93002337 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:55 #1 0x00007f4f93003a28 in __GI_abort () at abort.c:90 #2 0x00007f4f93b2e7d5 in __gnu_cxx::__verbose_terminate_handler() () at ../../../../libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x00007f4f93b2c746 in __cxxabiv1::__terminate(void (*)()) (handler=<optimized out>) at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 #4 0x00007f4f93b2c773 in std::terminate() () at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48 #5 0x00007f4f93b2c993 in __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) (obj=0x260d4b0, tinfo=0x7f4f966c1930 <typeinfo for Glib::ConvertError>, dest=0x7f4f96486fa0 <Glib::ConvertError::~ConvertError()>) at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:87 #6 0x00007f4f96486e27 in Glib::ConvertError::throw_func(_GError*) (gobject=0x260bf90) at convert.cc:329 #7 0x00007f4f9649b5d7 in Glib::Error::throw_exception(_GError*) (gobject=0x260bf90) at error.cc:175 #8 0x00007f4f964a7155 in Glib::operator<<(std::ostream&, Glib::ustring const&) (os=warning: RTTI symbol not found for class 'std::ostream' ..., utf8_string=...) at ustring.cc:1430 #9 0x000000000044d66f in GParted::Utils::execute_command(Glib::ustring const&, char const*, Glib::ustring&, Glib::ustring&, bool) (command=..., input=input@entry=0x0, output=..., error=..., use_C_locale=use_C_locale@entry=true) at ../src/Utils.cc:688 #10 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&) (use_C_locale=true, error=..., output=..., command=...) at ../src/Utils.cc:659 #11 0x000000000044dae9 in GParted::Utils::kernel_supports_fs(Glib::ustring const&) (fs=...) at ../src/Utils.cc:480 #12 0x0000000000460008 in GParted::jfs::get_filesystem_support() (this=0x25e8e60) at ../src/jfs.cc:59 #13 0x00000000004464f9 in GParted::SupportedFileSystems::find_supported_filesystems() (this=0x25e8690) at ../src/SupportedFileSystems.cc:120 #14 0x0000000000412360 in GParted::SupportedFileSystemsTest::setup_supported_filesystems() () at test_SupportedFileSystems.cc:278 #15 0x00000000004151b0 in GParted::SupportedFileSystemsTest::get_supported_fstypes() () at test_SupportedFileSystems.cc:256 #16 0x00000000004152c0 in GParted::gtest_MySupportedFileSystemsTest_EvalGenerator_() () at test_SupportedFileSystems.cc:495 #17 0x000000000041c7d6 in testing::internal::ParameterizedTestCaseInfo<GParted::SupportedFileSystemsTest>::RegisterTests() (this=0x2528ac0) at ../lib/gtest/include/gtest/internal/gtest-param-util.h:549 #18 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests() (this=0x25288d0) at ./include/gtest/internal/gtest-param-util.h:709 #19 0x0000000000479fb5 in testing::internal::UnitTestImpl::RegisterParameterizedTests() (this=this@entry=0x2528800) at ./src/gtest.cc:2658 #20 0x000000000048a001 in testing::internal::UnitTestImpl::PostFlagParsingInit() (this=0x2528800) at ./src/gtest.cc:4980 #21 0x000000000049e399 in testing::internal::InitGoogleTestImpl<char>(int*, char**) (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5934 #22 0x000000000048d285 in testing::InitGoogleTest(int*, char**) (argc=argc@entry=0x7ffe9d208a3c, argv=argv@entry=0x7ffe9d208b38) at ./src/gtest.cc:5952 #23 0x0000000000410404 in main(int, char**) (argc=1, argv=0x7ffe9d208b38) at test_SupportedFileSystems.cc:557 The test program runs when executed in my locale and produces these messages: $ ./test_SupportedFileSystems Running main() from test_SupportedFileSystems.cc Failed to execute child process “modprobe” (No such file or directory) Failed to execute child process “modprobe” (No such file or directory) [==========] Running 210 tests from 1 test case. ... So the test program is aborting when trying to print the failed to execute child process message, but only in the C locale. This doesn't affect the CentOS GitLab CI image because that installs the kmod package with modprobe by default, however the Ubuntu image doesn't have the kmod package. Fix this by explicitly installing the kmod package into both the CentOS and Ubuntu GitLab CI images. Closes !49 - Add file system interface tests
2019-10-16 00:36:41 -06:00
xorg-x11-server-Xvfb kmod
Fix CentOS 7 CI test job failures from empty /etc/machine-id (!62) Since August 2020, GitLab Continuous Integration test jobs have been failing on the CentOS 7 image like this from tests/test_SupportedFileSystems.log: process 6319: D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/etc/machine-id' should contain a hex string of length 32, not length 0, with no other text See the manual page for dbus-uuidgen to correct this issue. D-Bus not built with -rdynamic so unable to print a backtrace Running main() from test_SupportedFileSystems.cc DISPLAY=":99" /usr/bin/xvfb-run: line 181: 6319 Aborted (core dumped) DISPLAY=:$SERVERNUM XAUTHORITY=$AUTHFILE "$@" 2>&1 Not sure why this has just started failing in the CentOS 7 CI image now, but the error is widely known [1][2][3][4]. Use systemd-machine-id-setup to generate a machine ID [5][6]; rather than dbus-uuidgen [7] as it's designed to integrate into VMs and does the right thing if a valid machine ID already exists. [1] Red Hat Bug 598200 - D-Bus library appears to be incorrectly set up; failed to read machine uuid: UUID file '/var/lib/dbus/machine-id' https://bugzilla.redhat.com/show_bug.cgi?id=598200 [2] Free Desktop Bug 13194 - When machine-id not found, dbus should not abort https://bugs.freedesktop.org/show_bug.cgi?id=13194 [3] D-Bus library appears to be incorrectly set up https://unix.stackexchange.com/questions/117741/d-bus-library-appears-to-be-incorrectly-set-up [4] Generate uuid for container https://xpra.org/trac/wiki/Usage/Docker/CentOS [5] CentOS / RHEL 7 : How to Change the machine-id https://www.thegeekdiary.com/centos-rhel-7-how-to-change-the-machine-id/ [6] man systemd-machine-id-setup https://man7.org/linux/man-pages/man1/systemd-machine-id-setup.1.html [7] man dbus-uuidgen https://dbus.freedesktop.org/doc/dbus-uuidgen.1.html Closes !62 - Fix CentOS 7 CI test job failures because of zero sized /etc/machine-id
2020-09-17 09:44:31 -06:00
- systemd-machine-id-setup
.ubuntu_image_template: &ubuntu_image_definition
# Use official Ubuntu image https://hub.docker.com/_/ubuntu/.
image: ubuntu:latest
before_script:
- cat /proc/version
- cat /etc/os-release
Prevent tzdata install hang in GitLab CI Ubuntu image (!60) The Ubuntu based GitLab CI jobs have recently started being terminated after the default 1 hour timeout. Installing / updating packages in the image is updating the tzdata package which is prompting for input which it will never receive, hence the hang. The end of output from the job looks like this: Setting up tzdata (2020a-0ubuntu0.20.04) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline Configuring tzdata ------------------ Please select the geographic area in which you live. Subsequent configuration questions will narrow this down by presenting a list of cities, representing the time zones in which they are located. 1. Africa 4. Australia 7. Atlantic 10. Pacific 13. Etc 2. America 5. Arctic 8. Europe 11. SystemV 3. Antarctica 6. Asia 9. Indian 12. US Geographic area: ... ERROR: Job failed: execution took longer than 1h0m0s seconds This is a well known issue [1][2][3]. Probably occurring now because of a new release of tzdata not included in the base Ubuntu image we are using. Fix by telling the underlying dpkg tools this installation is non-interactive. [1] Avoiding user interaction with tzdata when installing certbot in a docker container https://askubuntu.com/questions/909277/avoiding-user-interaction-with-tzdata-when-installing-certbot-in-a-docker-contai [2] How to install tzdata on a ubuntu docker image? https://serverfault.com/questions/949991/how-to-install-tzdata-on-a-ubuntu-docker-image [3] apt-get install tzdata noninteractive https://stackoverflow.com/questions/44331836/apt-get-install-tzdata-noninteractive Closes !60 - Fix GitLab CI job failures following Ubuntu docker image updates
2020-05-22 08:59:35 -06:00
- export DEBIAN_FRONTEND=noninteractive
- apt update
- apt install -y build-essential gnome-common yelp-tools libglib2.0-dev-bin
uuid-dev libparted-dev libgtkmm-3.0-dev 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.
- apt install -y btrfs-progs e2fsprogs exfatprogs f2fs-tools dosfstools
mtools hfsutils hfsprogs jfsutils util-linux cryptsetup-bin
dmsetup lvm2 nilfs-tools ntfs-3g reiser4progs reiserfsprogs
udftools xfsprogs xfsdump xvfb kmod
.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
# Save all files on job failure for investigation.
artifacts:
when: on_failure
name: "$CI_PROJECT_NAME-ci-job-$CI_JOB_ID-$CI_JOB_NAME"
untracked: true
paths:
- ./
expire_in: 1 week
.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 tests needing losetup in Docker CI image (!59) test_SupportedFileSystems is another unit test that has been failing since 23-Feb-2020 in GNOME GitLab Continuous Integration test jobs. Fragments from tests/test-suite.log from a failed test CI job: FAIL: test_SupportedFileSystems =============================== ... [ RUN ] My/SupportedFileSystemsTest.Create/lvm2pv test_SupportedFileSystems.cc:387: Failure Failed create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img' losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory create_loopdev(): Losetup failed with exit status 1 create_loopdev(): Failed to create required loop device Error: Could not stat device - No such file or directory. test_SupportedFileSystems.cc:446: Failure Value of: lp_device != NULL Actual: false Expected: true test_SupportedFileSystems.cc:490: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: lvm pvcreate -M 2 '' 00:00:00 (ERROR) WARNING: Failed to connect to lvmetad. Falling back to device scanning. Device not found. detach_loopdev(): Execute: losetup --detach '' losetup: /dev/: detach failed: Inappropriate ioctl for device detach_loopdev(): Losetup failed with exit status 1 detach_loopdev(): Failed to detach loop device. Test NOT affected [ FAILED ] My/SupportedFileSystemsTest.Create/lvm2pv, where GetParam() = 20 (64 ms) ... [ RUN ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs test_SupportedFileSystems.cc:387: Failure Failed create_loopdev(): Execute: losetup --find --show 'test_SupportedFileSystems.img' losetup: test_SupportedFileSystems.img: failed to set up loop device: No such file or directory create_loopdev(): Losetup failed with exit status 1 create_loopdev(): Failed to create required loop device Error: Could not stat device - No such file or directory. test_SupportedFileSystems.cc:446: Failure Value of: lp_device != NULL Actual: false Expected: true test_SupportedFileSystems.cc:503: Failure Value of: m_fs_object->create(m_partition, m_operation_detail) Actual: false Expected: true Operation details: mkfs.btrfs -L '' '' 00:00:00 (ERROR) btrfs-progs v4.9.1 See http://btrfs.wiki.kernel.org for more information. ERROR: failed to check size for : No such file or directory detach_loopdev(): Execute: losetup --detach '' losetup: /dev/: detach failed: Inappropriate ioctl for device detach_loopdev(): Losetup failed with exit status 1 detach_loopdev(): Failed to detach loop device. Test NOT affected [ FAILED ] My/SupportedFileSystemsTest.CreateAndReadUsage/btrfs, where GetParam() = 7 (11 ms) All the test_SupportedFileSystems unit tests which need a loop device are failing when running losetup like this: losetup: <IMAGE_NAME>: failed to setup loop device: No such file or directory losetup uses /dev/loop-control [1][2] which no longer exists in the Docker image. However even after creating /dev/loop-control in the image, losetup continues to fail. Also tried stracing losetup but that fails like this, presumably because it is not allowed inside the Docker image: $ strace losetup --find --show /tmp/disk.img strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted +++ exited with 1 +++ For now I have run out of ways to investigate and resolve this, so just exclude the 12 tests which required loop devices. All the tests still execute when run locally outside the restricted GNOME GitLab CI Docker setup. Closes !59 - Fix GNOME GitLab CI test job failures because of missing /dev entries
2020-03-11 01:55:53 -06:00
# Exclude specific unit tests which fail without being able to create
# loop devices in Docker images.
- export GTEST_FILTER=`tests/exclude_loopdev_tests.sh tests/test_SupportedFileSystems.cc`
- echo $GTEST_FILTER
- fgrep -v nodev /proc/filesystems | sort
- cat /proc/partitions
- ls -l /dev
Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) From 23-Feb-2020 onwards, GNOME GitLab Continuous Integration test jobs have been failing running unit tests which previously succeeded. With some extra debugging added into test_BlockSpecial to print 'bname' and 'bs' values in the failing tests, here are fragments from tests/test-suite.log for the the test_BlockSpecial failures in a test CI job: FAIL: test_BlockSpecial ======================= ... [ RUN ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice bname="/dev/sr0" bs=BlockSpecial{"/dev/sr0",0,0} test_BlockSpecial.cc:218: Failure Value of: bs.m_major > 0 || bs.m_minor > 0 Actual: false Expected: true [ FAILED ] BlockSpecialTest.NamedBlockSpecialObjectBlockDevice (0 ms) ... [ RUN ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices bname1="/dev/sr0" bname2="/dev/sda" bs1=BlockSpecial{"/dev/sr0",0,0} bs2=BlockSpecial{"/dev/sda",0,0} test_BlockSpecial.cc:250: Failure Value of: bs1.m_major != bs2.m_major || bs1.m_minor != bs2.m_minor Actual: false Expected: true [ FAILED ] BlockSpecialTest.TwoNamedBlockSpecialObjectBlockDevices (1 ms) Contents of /proc/partitions inside the Docker image when this test CI job failed: $ cat /proc/partitions major minor #blocks name 11 0 1048575 sr0 8 0 573367448 sda 8 1 573366407 sda1 And the listing of /dev/: $ ls -l /dev/ total 0 lrwxrwxrwx 1 root root 11 Mar 3 09:00 core -> /proc/kcore lrwxrwxrwx 1 root root 13 Mar 3 09:00 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Mar 3 09:00 full drwxrwxrwt 2 root root 40 Mar 3 09:00 mqueue crw-rw-rw- 1 root root 1, 3 Mar 3 09:00 null lrwxrwxrwx 1 root root 8 Mar 3 09:00 ptmx -> pts/ptmx drwxr-xr-x 2 root root 0 Mar 3 09:00 pts crw-rw-rw- 1 root root 1, 8 Mar 3 09:00 random drwxrwxrwt 2 root root 40 Mar 3 09:00 shm lrwxrwxrwx 1 root root 15 Mar 3 09:00 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Mar 3 09:00 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Mar 3 09:00 tty crw-rw-rw- 1 root root 1, 9 Mar 3 09:00 urandom crw-rw-rw- 1 root root 1, 5 Mar 3 09:00 zero See how the test_BlockSpecial fixtures are getting major=0 and minor=0 for the block special devices they are testing with. This is happening because there aren't any entries in /dev for those disks and partitions listed in /proc/partitions. Assume that Docker in GNOME GitLab has changed and that unneeded and unwanted devices in /dev are no longer being created inside images. In the test CI jobs execute new script, tests/makedev.sh, to create just the first two block special devices mentioned in /proc/partitions needed by test_BlockSpecial. Closes !59 - Fix GNOME GitLab CI test job failures because of missing /dev entries
2020-03-08 03:34:15 -06:00
# Create needed /dev entries for unit tests in Docker images.
- tests/makedev.sh
- make check
- make distcheck
- fgrep -v nodev /proc/filesystems | sort
# Save all files on job failure for investigation.
artifacts:
when: on_failure
name: "$CI_PROJECT_NAME-ci-job-$CI_JOB_ID-$CI_JOB_NAME"
untracked: true
paths:
- ./
expire_in: 1 week
# Check GParted can be built and installed on Alpine Linux, CentOS and Ubuntu.
alpine_build:
<<: *alpine_image_definition
<<: *build_stage_definition
centos_build:
<<: *centos_image_definition
<<: *build_stage_definition
ubuntu_build:
<<: *ubuntu_image_definition
<<: *build_stage_definition
# Check GParted unit tests and distcheck pass on Alpine Linux, CentOS and
# Ubuntu.
alpine_test:
<<: *alpine_image_definition
<<: *test_stage_definition
centos_test:
<<: *centos_image_definition
<<: *test_stage_definition
ubuntu_test:
<<: *ubuntu_image_definition
<<: *test_stage_definition