Mirrors
/
gparted
mirror of https://gitlab.gnome.org/GNOME/gparted.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
gparted/.gitlab-ci.yml

67 lines
2.0 KiB
YAML
Raw Normal View History

Create initial GitLab CI job which builds on CentOS (!4) Initial GitLab Continuous Integration configuration with a single job named 'build' which just confirms GParted can be built and installed on the latest official CentOS Docker image. Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 03:31:33 -06:00
stages:
- build
Add CI testing job on CentOS (!4) Add GitLab Continuous Integration job named 'test' which runs the GParted unit tests and distcheck. Note that the job starts from a fresh official CentOS Docker image so also has to rebuild GParted too. So far this job fails on unit test test_BlockSpecial. Fragment of the CI job log: make check-TESTS make[2]: Entering directory `/builds/mfleetwo/gparted/tests' make[3]: Entering directory `/builds/mfleetwo/gparted/tests' PASS: test_dummy FAIL: test_BlockSpecial PASS: test_PasswordRAMStore PASS: test_PipeCapture make[4]: Entering directory `/builds/mfleetwo/gparted/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/builds/mfleetwo/gparted/tests' ============================================================================ Testsuite summary for gparted 0.31.0-git ============================================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted ============================================================================ Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 05:56:01 -06:00
- test
Create initial GitLab CI job which builds on CentOS (!4) Initial GitLab Continuous Integration configuration with a single job named 'build' which just confirms GParted can be built and installed on the latest official CentOS Docker image. Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 03:31:33 -06:00
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
.centos_image_template: &centos_image_definition
# Use official CentOS image https://hub.docker.com/_/centos/.
Remain with CentOS 7 for GitLab CI (!48) When GParted GitLab Continuous Integration was setup, CentOS 7 image was used for a slow moving distribution and Ubuntu as a different, faster moving distribution. CentOS 8 has recently been released [1]. To avoid automatically switching to it when an official CentOS 8 docker image is made available [2], explicitly specify the CentOS 7 image. [1] Release for CentOS Linux 8 and CentOS Streams (2019-09-24) https://lists.centos.org/pipermail/centos-announce/2019-September/023449.html [2] Docker Official Images, The official build of CentOS https://hub.docker.com/_/centos/ Closes !48 - Remain with CentOS 7 for GitLab CI
2019-09-29 03:13:49 -06:00
image: centos:centos7
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
before_script:
- yum update -y
Add use of new GNOME 3 yelp-tools documentation infrastructure (!24) Second part is to use yelp-tools to build and install the documentation. Have to rename the help Manual from help/C/gparted.xml to help/C/index.docbook in accordance with this note from the GNOME Goal: Port to New Documentation Infrastructure [1]: IMPORTANT: If this is for a DocBook document, the top-level DocBook file MUST be renamed to index.docbook. Do a "git mv" and include index.docbook in HELP_FILES. Commits from gucharmap [4] and totem [5], projects which have DocBook documentation, making this same change are also useful references. [1] GNOME Goal: Port To New Documentation Infrastructure https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure [2] Yelp > Yelp Tools > yelp.m4 http://yelp.io/tools/yelp.m4.html [3] GNOME application developement overview / User help / Set up your build system https://developer.gnome.org/platform-overview/stable/dev-help-build.html.en [4] gucharmap commit "Port to new documentation infrastructure" https://gitlab.gnome.org/GNOME/gucharmap/commit/3e1526c0568f0b395fce68f9d9e09431dfcaef35 [5] totem commit "Use new documentation infrastructure" https://gitlab.gnome.org/GNOME/totem/commit/59a6bd6064fe7dd047f7b61642aba73e0ba72acf Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-02-23 03:39:57 -07:00
- yum install -y which gnome-common yelp-tools glib2-devel intltool
port-to-gtk3: Switch to Gtkmm3 (#7) Switch to Gtkmm3 in configure.ac. Require version 3.0.0. Also update the build instructions in README and the package list in .gitlab-ci.yml. Starting from version 3.18.0 Gtkmm requires C++11 compilation [1][2][3]. Add a check for Gtkmm >= 3.18.0 in configure.ac and enable C++11 compilation accordingly. References: [1] Gtkmm 3.18.1 NEWS "Changes in 3.18 ... Use, and require C++11, ..." https://gitlab.gnome.org/GNOME/gtkmm/blob/3.18.1/NEWS#L35 [2] Murray's Blog - "gtkmm now uses C++11" https://www.murrayc.com/permalink/2015/07/31/gtkmm-now-uses-c11 [3] Murray's Blog - "gtkmm 3.18 and glibmm 2.46" https://www.murrayc.com/permalink/2015/09/25/gtkmm-3-18-and-glibmm-2-46 Closes #7 - Port to Gtk3
2018-08-27 11:58:56 -06:00
gcc-c++ libuuid-devel parted-devel gtkmm30-devel make
Remove use of GNOME 2 gnome-doc-utils documentation infrastructure (!24) Details of old GNOME 2 gnome-doc-utils: Migrating your documentation to gnome-doc-utils https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo First part is to stop using gnome-doc-utils to build and install the documentation. Also since updating the OMF catalog was only needed for GNOME 2 yelp, use of scrollkeeper is completely removed too. Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-02-21 09:30:03 -07:00
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
Print OS details in the GitLab CI (!48) Just a simple debugging aid to have the OS details printed in the GitLab CI output. Closes !48 - Remain with CentOS 7 for GitLab CI
2019-09-29 03:36:57 -06:00
- cat /etc/os-release
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
Add CI job to build GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:47:43 -06:00
.ubuntu_image_template: &ubuntu_image_definition
# Use official Ubuntu image https://hub.docker.com/_/ubuntu/.
image: ubuntu:latest
before_script:
- apt-get update
Add use of new GNOME 3 yelp-tools documentation infrastructure (!24) Second part is to use yelp-tools to build and install the documentation. Have to rename the help Manual from help/C/gparted.xml to help/C/index.docbook in accordance with this note from the GNOME Goal: Port to New Documentation Infrastructure [1]: IMPORTANT: If this is for a DocBook document, the top-level DocBook file MUST be renamed to index.docbook. Do a "git mv" and include index.docbook in HELP_FILES. Commits from gucharmap [4] and totem [5], projects which have DocBook documentation, making this same change are also useful references. [1] GNOME Goal: Port To New Documentation Infrastructure https://wiki.gnome.org/Initiatives/GnomeGoals/NewDocumentationInfrastructure [2] Yelp > Yelp Tools > yelp.m4 http://yelp.io/tools/yelp.m4.html [3] GNOME application developement overview / User help / Set up your build system https://developer.gnome.org/platform-overview/stable/dev-help-build.html.en [4] gucharmap commit "Port to new documentation infrastructure" https://gitlab.gnome.org/GNOME/gucharmap/commit/3e1526c0568f0b395fce68f9d9e09431dfcaef35 [5] totem commit "Use new documentation infrastructure" https://gitlab.gnome.org/GNOME/totem/commit/59a6bd6064fe7dd047f7b61642aba73e0ba72acf Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-02-23 03:39:57 -07:00
- apt-get install -y gnome-common yelp-tools libglib2.0-dev-bin
port-to-gtk3: Switch to Gtkmm3 (#7) Switch to Gtkmm3 in configure.ac. Require version 3.0.0. Also update the build instructions in README and the package list in .gitlab-ci.yml. Starting from version 3.18.0 Gtkmm requires C++11 compilation [1][2][3]. Add a check for Gtkmm >= 3.18.0 in configure.ac and enable C++11 compilation accordingly. References: [1] Gtkmm 3.18.1 NEWS "Changes in 3.18 ... Use, and require C++11, ..." https://gitlab.gnome.org/GNOME/gtkmm/blob/3.18.1/NEWS#L35 [2] Murray's Blog - "gtkmm now uses C++11" https://www.murrayc.com/permalink/2015/07/31/gtkmm-now-uses-c11 [3] Murray's Blog - "gtkmm 3.18 and glibmm 2.46" https://www.murrayc.com/permalink/2015/09/25/gtkmm-3-18-and-glibmm-2-46 Closes #7 - Port to Gtk3
2018-08-27 11:58:56 -06:00
uuid-dev libparted-dev libgtkmm-3.0-dev make
Remove use of GNOME 2 gnome-doc-utils documentation infrastructure (!24) Details of old GNOME 2 gnome-doc-utils: Migrating your documentation to gnome-doc-utils https://wiki.gnome.org/Projects/GnomeDocUtils/MigrationHowTo First part is to stop using gnome-doc-utils to build and install the documentation. Also since updating the OMF catalog was only needed for GNOME 2 yelp, use of scrollkeeper is completely removed too. Closes !24 - Port to GNOME 3 yelp-tools documentation infrastructure
2019-02-21 09:30:03 -07:00
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
Print OS details in the GitLab CI (!48) Just a simple debugging aid to have the OS details printed in the GitLab CI output. Closes !48 - Remain with CentOS 7 for GitLab CI
2019-09-29 03:36:57 -06:00
- cat /etc/os-release
Add CI job to build GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:47:43 -06:00
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
.build_stage_template: &build_stage_definition
Create initial GitLab CI job which builds on CentOS (!4) Initial GitLab Continuous Integration configuration with a single job named 'build' which just confirms GParted can be built and installed on the latest official CentOS Docker image. Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 03:31:33 -06:00
stage: build
script:
- ./autogen.sh
Parallelise building GParted in GitLab CI jobs (!6) Reduce the time taken by the GitLab Continuous Integration jobs by parallelising make to use all available CPUs in the Docker CI image when it is building GParted code. This includes 'make diskcheck' because that also does a second build of the GParted code in a separate subdirectory. Closes !6 - Reduce the time taken by the GitLab CI jobs
2018-07-06 00:35:10 -06:00
- nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1
- echo nproc=$nproc
- make -j $nproc
Create initial GitLab CI job which builds on CentOS (!4) Initial GitLab Continuous Integration configuration with a single job named 'build' which just confirms GParted can be built and installed on the latest official CentOS Docker image. Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 03:31:33 -06:00
- make install
Add CI testing job on CentOS (!4) Add GitLab Continuous Integration job named 'test' which runs the GParted unit tests and distcheck. Note that the job starts from a fresh official CentOS Docker image so also has to rebuild GParted too. So far this job fails on unit test test_BlockSpecial. Fragment of the CI job log: make check-TESTS make[2]: Entering directory `/builds/mfleetwo/gparted/tests' make[3]: Entering directory `/builds/mfleetwo/gparted/tests' PASS: test_dummy FAIL: test_BlockSpecial PASS: test_PasswordRAMStore PASS: test_PipeCapture make[4]: Entering directory `/builds/mfleetwo/gparted/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/builds/mfleetwo/gparted/tests' ============================================================================ Testsuite summary for gparted 0.31.0-git ============================================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted ============================================================================ Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 05:56:01 -06:00
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
.test_stage_template: &test_stage_definition
Add CI testing job on CentOS (!4) Add GitLab Continuous Integration job named 'test' which runs the GParted unit tests and distcheck. Note that the job starts from a fresh official CentOS Docker image so also has to rebuild GParted too. So far this job fails on unit test test_BlockSpecial. Fragment of the CI job log: make check-TESTS make[2]: Entering directory `/builds/mfleetwo/gparted/tests' make[3]: Entering directory `/builds/mfleetwo/gparted/tests' PASS: test_dummy FAIL: test_BlockSpecial PASS: test_PasswordRAMStore PASS: test_PipeCapture make[4]: Entering directory `/builds/mfleetwo/gparted/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/builds/mfleetwo/gparted/tests' ============================================================================ Testsuite summary for gparted 0.31.0-git ============================================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted ============================================================================ Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 05:56:01 -06:00
stage: test
script:
- ./autogen.sh
Parallelise building GParted in GitLab CI jobs (!6) Reduce the time taken by the GitLab Continuous Integration jobs by parallelising make to use all available CPUs in the Docker CI image when it is building GParted code. This includes 'make diskcheck' because that also does a second build of the GParted code in a separate subdirectory. Closes !6 - Reduce the time taken by the GitLab CI jobs
2018-07-06 00:35:10 -06:00
- 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'
Add CI testing job on CentOS (!4) Add GitLab Continuous Integration job named 'test' which runs the GParted unit tests and distcheck. Note that the job starts from a fresh official CentOS Docker image so also has to rebuild GParted too. So far this job fails on unit test test_BlockSpecial. Fragment of the CI job log: make check-TESTS make[2]: Entering directory `/builds/mfleetwo/gparted/tests' make[3]: Entering directory `/builds/mfleetwo/gparted/tests' PASS: test_dummy FAIL: test_BlockSpecial PASS: test_PasswordRAMStore PASS: test_PipeCapture make[4]: Entering directory `/builds/mfleetwo/gparted/tests' make[4]: Nothing to be done for `all'. make[4]: Leaving directory `/builds/mfleetwo/gparted/tests' ============================================================================ Testsuite summary for gparted 0.31.0-git ============================================================================ # TOTAL: 4 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 ============================================================================ See tests/test-suite.log Please report to https://bugzilla.gnome.org/enter_bug.cgi?product=gparted ============================================================================ Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-22 05:56:01 -06:00
- make check
Stop parallelising make distcheck in GitLab CI test jobs (!6) Unfortunately parallelising 'make distcheck' causes it to fail like this: $ nproc=`grep -c '^processor' /proc/cpuinfo` || nproc=1 $ echo nproc=$nproc nproc=8 ... $ make -j $nproc distcheck ... make[1]: Entering directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub' ERROR: files left after uninstall: ./share/icons/hicolor/icon-theme.cache Makefile:896: recipe for target 'distuninstallcheck' failed make[1]: Leaving directory '/builds/mfleetwo/gparted/gparted-0.31.0-git/_build/sub' make[1]: *** [distuninstallcheck] Error 1 make: *** [distcheck] Error 1 Makefile:840: recipe for target 'distcheck' failed ERROR: Job failed: exit code 1 Therefore go back to serial 'make distcheck'. Closes !6 - Reduce the time taken by the GitLab CI jobs
2018-07-06 04:28:55 -06:00
- make distcheck
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
Add CI job to build GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:47:43 -06:00
# Check GParted can be built and installed on CentOS and Ubuntu.
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
centos_build:
<<: *centos_image_definition
<<: *build_stage_definition
Add CI job to build GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:47:43 -06:00
ubuntu_build:
<<: *ubuntu_image_definition
<<: *build_stage_definition
Add CI job to test GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-24 06:51:21 -06:00
# Check GParted unit tests and distcheck pass on CentOS and Ubuntu.
Parameterise CI config ready for also using a Ubuntu image (!4) Prepare the GitLab Continuous Integration configuration for also building and testing GParted on a Ubuntu image. The definition of the image and before_script, which so far specify the CentOS Docker image and how to install the required RPM packages, need to move from being top level nodes to being defined per job. Namely within jobs 'centos_build' and 'centos_test'. To avoid duplicating various nodes within multiple jobs, YAML anchors (&LABEL) and references (*LABEL) are used. They are defined in ignored jobs, job names starting with a dot (.). Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-23 06:28:57 -06:00
centos_test:
<<: *centos_image_definition
<<: *test_stage_definition
Add CI job to test GParted on Ubuntu (!4) Closes !4 - Add GitLab CI jobs to build and test GParted
2018-06-24 06:51:21 -06:00
ubuntu_test:
<<: *ubuntu_image_definition
<<: *test_stage_definition