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

127 lines
4.2 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
Add Alpine Linux CI build job (!104) There have been a number of GParted build issues [1][2] recently on Alpine Linux because it uses musl libc [3] which is stricter to POSIX, rather than the GNU C Library (glibc) which has numerous enhancements. Glibc is used by most Linux distributions, including CentOS and Ubuntu already used in the GNOME Continuous Integration jobs. So add a GParted build job on Alpine Linux to catch these issues in future. Uses the docker image of the latest Alpine Linux release. [1] 3d4b1c1e7b33f229efd254fb0cc06660af627ea0 Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) [2] 45c00927b72319f00855c7feaf4dcf109b3e4414 Use POSIX basename() in BCache_Info.cc (!99) [3] musl libc https://musl.libc.org/ Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 05:01:12 -06:00
.alpine_image_template: &alpine_image_definition
# Use official Alpine image https://hub.docker.com/_/alpine/.
Stick with Alpine Linux 3.17 in the GitLab CI images Alpine Linux just released new docker image 3.18, updating latest from 3.17 [1], which causes the GNOME GitLab CI jobs to fail like this: $ apk add gnome-common yelp-tools automake autoconf glib-dev libtool g++ parted-dev gtkmm3-dev itstool make git polkit-dev ERROR: unable to select packages: gnome-common (no such package): required by: world[gnome-common] Based on this blog [2] I printed the apk repository configuration file in Alpine Linux 3.17 and 3.18 docker images in GitLab CI jobs and found this contents: Alpine Linux 3.17 $ cat /etc/apk/repositories https://dl-cdn.alpinelinux.org/alpine/v3.17/main https://dl-cdn.alpinelinux.org/alpine/v3.17/community Alpine Linux 3.18 $ cat /etc/apk/repositories https://dl-cdn.alpinelinux.org/alpine/v3.18/main https://dl-cdn.alpinelinux.org/alpine/v3.18/community So what I conclude is that the packages GParted needs aren't yet available or being distributed for Alpine Linux 3.18. Therefore fix this by explicitly sticking with Alpine Linux 3.17. [1] Alpine docker images https://hub.docker.com/_/alpine/ * 3.18.0, 3.18, 3, latest https://github.com/alpinelinux/docker-alpine/blob/571516c7ce3ecec3c70541d13529a4abb33ba362/x86_64/Dockerfile Committed 2023-May-09 [2] ERROR: unable to select packages error on Alpine Linux https://www.hasanaltin.com/error-unable-to-select-packages-error-on-alpine-linux/
2023-05-11 06:58:58 -06:00
image: alpine:3.17
Add Alpine Linux CI build job (!104) There have been a number of GParted build issues [1][2] recently on Alpine Linux because it uses musl libc [3] which is stricter to POSIX, rather than the GNU C Library (glibc) which has numerous enhancements. Glibc is used by most Linux distributions, including CentOS and Ubuntu already used in the GNOME Continuous Integration jobs. So add a GParted build job on Alpine Linux to catch these issues in future. Uses the docker image of the latest Alpine Linux release. [1] 3d4b1c1e7b33f229efd254fb0cc06660af627ea0 Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) [2] 45c00927b72319f00855c7feaf4dcf109b3e4414 Use POSIX basename() in BCache_Info.cc (!99) [3] musl libc https://musl.libc.org/ Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 05:01:12 -06:00
before_script:
- cat /proc/version
- cat /etc/os-release
- apk update
Stop installing intltool package into Alpine and CentOS CI images (!107) ... as the GParted build no longer uses it. (Intltool is not explicitly installed into the Ubuntu CI image). However removing intltool from the GitLab CentOS Continuous Integration image causes the build job to fail like this: $ ./autogen.sh ... **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. Processing ./configure.ac Running autoreconf... autoreconf: Entering directory `.' autoreconf: running: autopoint --force Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345. autoreconf: failed to run autopoint: No such file or directory autoreconf: autopoint is needed because this package uses Gettext This is because on CentOS 7 autopoint is provided by the gettext-devel package which was installed as a requirement for intltool. Fix the build by explicitly installing the package. (On Alpine Linux the gettext-dev package is automatically installed and on Ubuntu the autopoint package is automatically installed so those CI images don't need to explicitly include the relevant package). Closes !107 - Migrate from intltool to gettext translation
2022-09-23 01:33:15 -06:00
- apk add gnome-common yelp-tools automake autoconf glib-dev libtool g++
parted-dev gtkmm3-dev itstool make git polkit-dev
Add Alpine Linux CI test job (!104) Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 06:47:28 -06:00
# 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
Add Alpine Linux CI build job (!104) There have been a number of GParted build issues [1][2] recently on Alpine Linux because it uses musl libc [3] which is stricter to POSIX, rather than the GNU C Library (glibc) which has numerous enhancements. Glibc is used by most Linux distributions, including CentOS and Ubuntu already used in the GNOME Continuous Integration jobs. So add a GParted build job on Alpine Linux to catch these issues in future. Uses the docker image of the latest Alpine Linux release. [1] 3d4b1c1e7b33f229efd254fb0cc06660af627ea0 Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) [2] 45c00927b72319f00855c7feaf4dcf109b3e4414 Use POSIX basename() in BCache_Info.cc (!99) [3] musl libc https://musl.libc.org/ Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 05:01:12 -06:00
Replace CentOS 7 with Rocky Linux 8 in the CI jobs (!124) CentOS reached its end of life on 30 June 2024 and has been discontinued [1][2]. Instead switch to Rocky Linux 8 which is an open-source rebuild of RHEL 8 [3]. [1] What to know about CentOS Linux EOL https://www.redhat.com/en/topics/linux/centos-linux-eol [2] CentOS Linux is going End of Life, What does that mean for me? https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me [3] Rocky Linux https://rockylinux.org/ Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:42:27 -06:00
.rocky_image_template: &rocky_image_definition
# Use official Rocky Linux image https://hub.docker.com/_/rockylinux/.
image: rockylinux:8
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:
Print kernel and OS details first in the GitLab CI jobs When the CentOS 7 CI jobs were failing on a subset of the job runners [1] during March to May 2022, the docker image would hang even before the packages were fully installed so cat /proc/version and cat /etc/os-release were never run. Move them to the first thing done in the docker image. [1] Hanging of GitLab CI jobs on a subset of job runners https://discourse.gnome.org/t/hanging-of-gitlab-ci-jobs-on-a-subset-of-job-runners/9931
2022-06-18 14:35:58 -06:00
- cat /proc/version
- cat /etc/os-release
Replace CentOS 7 with Rocky Linux 8 in the CI jobs (!124) CentOS reached its end of life on 30 June 2024 and has been discontinued [1][2]. Instead switch to Rocky Linux 8 which is an open-source rebuild of RHEL 8 [3]. [1] What to know about CentOS Linux EOL https://www.redhat.com/en/topics/linux/centos-linux-eol [2] CentOS Linux is going End of Life, What does that mean for me? https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me [3] Rocky Linux https://rockylinux.org/ Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:42:27 -06:00
- dnf update -y
# Enable PowerTools repo for development packages.
- dnf install -y 'dnf-command(config-manager)'
- dnf config-manager --set-enabled powertools
- dnf install -y which gnome-common yelp-tools glib2-devel gcc-c++
Stop installing intltool package into Alpine and CentOS CI images (!107) ... as the GParted build no longer uses it. (Intltool is not explicitly installed into the Ubuntu CI image). However removing intltool from the GitLab CentOS Continuous Integration image causes the build job to fail like this: $ ./autogen.sh ... **Warning**: I am going to run `configure' with no arguments. If you wish to pass any to it, please specify them on the `./autogen.sh' command line. Processing ./configure.ac Running autoreconf... autoreconf: Entering directory `.' autoreconf: running: autopoint --force Can't exec "autopoint": No such file or directory at /usr/share/autoconf/Autom4te/FileUtils.pm line 345. autoreconf: failed to run autopoint: No such file or directory autoreconf: autopoint is needed because this package uses Gettext This is because on CentOS 7 autopoint is provided by the gettext-devel package which was installed as a requirement for intltool. Fix the build by explicitly installing the package. (On Alpine Linux the gettext-dev package is automatically installed and on Ubuntu the autopoint package is automatically installed so those CI images don't need to explicitly include the relevant package). Closes !107 - Migrate from intltool to gettext translation
2022-09-23 01:33:15 -06:00
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.
Replace CentOS 7 with Rocky Linux 8 in the CI jobs (!124) CentOS reached its end of life on 30 June 2024 and has been discontinued [1][2]. Instead switch to Rocky Linux 8 which is an open-source rebuild of RHEL 8 [3]. [1] What to know about CentOS Linux EOL https://www.redhat.com/en/topics/linux/centos-linux-eol [2] CentOS Linux is going End of Life, What does that mean for me? https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me [3] Rocky Linux https://rockylinux.org/ Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:42:27 -06:00
# Install EPEL repo first for exfatprogs and ntfsprogs.
- dnf install -y epel-release
- dnf install -y e2fsprogs dosfstools exfatprogs mtools util-linux
cryptsetup device-mapper lvm2 ntfsprogs udftools xfsprogs
xfsdump xorg-x11-server-Xvfb kmod
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:
Print kernel and OS details first in the GitLab CI jobs When the CentOS 7 CI jobs were failing on a subset of the job runners [1] during March to May 2022, the docker image would hang even before the packages were fully installed so cat /proc/version and cat /etc/os-release were never run. Move them to the first thing done in the docker image. [1] Hanging of GitLab CI jobs on a subset of job runners https://discourse.gnome.org/t/hanging-of-gitlab-ci-jobs-on-a-subset-of-job-runners/9931
2022-06-18 14:35:58 -06:00
- 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
Use apt to install packages on Debian and related distros Apt is the modern recommended command to use when installing packages these days on Debian and related distributions [1][2][3]. Convert the Ubuntu GitLab CI jobs and update the README accordingly. [1] What is the difference between apt and apt-get? https://askubuntu.com/questions/445384/what-is-the-difference-between-apt-and-apt-get [2] Difference Between apt and apt-get Explained https://itsfoss.com/apt-vs-apt-get-difference/ [2] Apt and Apt-get - Which One to Use https://linoxide.com/apt-and-apt-get-which-one-to-use/
2022-07-01 05:53:22 -06:00
- 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
Fix .policy file translation in Ubuntu CI docker image (!124) Now that the official Ubuntu latest docker image has updated to Ubuntu 24.04 LTS [1] the build CI job fails like this: $ make -j $nproc ... /usr/bin/msgfmt --desktop --template gparted.desktop.in -d ./po -o gparted.desktop /usr/bin/msgfmt --xml --template org.gnome.gparted.policy.in -d ./po -o org.gnome.gparted.policy /usr/bin/msgfmt: cannot locate ITS rules for org.gnome.gparted.policy.in make[2]: *** [Makefile:1060: org.gnome.gparted.policy] Error 1 The needed fix is already documented in the README file [2]. Install the required package into the Ubuntu CI docker images to fix this. [1] Ubuntu Docker official image https://hub.docker.com/_/ubuntu/ "Supported tags and respective Dockerfile links ... 24.04, ..., latest, ... " [2] 16c2533af090744683cccbfc0987000975f6b52f Document future Debian/Ubuntu build time dependency in README (!121) Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:06:39 -06:00
libpolkit-gobject-1-dev
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.
Use apt to install packages on Debian and related distros Apt is the modern recommended command to use when installing packages these days on Debian and related distributions [1][2][3]. Convert the Ubuntu GitLab CI jobs and update the README accordingly. [1] What is the difference between apt and apt-get? https://askubuntu.com/questions/445384/what-is-the-difference-between-apt-and-apt-get [2] Difference Between apt and apt-get Explained https://itsfoss.com/apt-vs-apt-get-difference/ [2] Apt and Apt-get - Which One to Use https://linoxide.com/apt-and-apt-get-which-one-to-use/
2022-07-01 05:53:22 -06:00
- 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
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
Save all files on CI job failure for investigation Since patchset !49 "Add file system interface tests" was merged the GitLab Continuous Integration jobs have sometimes failed executing test_SupportedFilesystems. So on failure save all files from the docker image for 1 week for investigation. Documentation: * Introduction to job artifacts https://gitlab.gnome.org/help/user/project/pipelines/job_artifacts.md * GitLab CI/CD Pipeline Configuration Reference, artifacts https://gitlab.gnome.org/help/ci/yaml/README.md#artifacts
2019-12-03 07:08:06 -07:00
# 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
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 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.
Automate exclusion of loop device tests from CI image (!105) Avoid having to manually maintain the list of excluded File System tests in the GitLab Docker CI image. Scan the unit test source extracting those tests marked with SKIP_IF_NOT_ROOT_FOR_REQUIRED_LOOPDEV_FOR_FS() to automatically construct the setting for the GTEST_FILTER environment variable. Closes !105 - Update used btrfs file system commands, new minimum is btrfs-progs 4.5
2022-07-04 11:30:15 -06:00
- export GTEST_FILTER=`tests/exclude_loopdev_tests.sh tests/test_SupportedFileSystems.cc`
- echo $GTEST_FILTER
Print kernel version, etc in GitLab CI (#147) Print the kernel version and supported file systems inside the GNOME GitLab CI jobs as a debugging aid. Kernel version helps identify the CI job runner's distribution to identify kernel features. Supported file systems identifies which ones can be mounted, should that be possible in future. Print supported file systems before and after the tests because checking for support may load additional modules. See calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs. Closes #147 - GitLab CI test failure from *.CreateAndGrow/jfs
2021-03-08 08:40:43 -07:00
- fgrep -v nodev /proc/filesystems | sort
Cat /proc/partitions and list /dev in GitLab CI test jobs (!113) Add these simple debugging aids to the GNOME GitLab CI test job. They've been needed before [1] so add them permanently. [1] 57983b9fc20c9367f9dd83a8301e903fced5329e Create block special devices needed by test_BlockSpecial in GitLab CI jobs (!59) "Contents of /proc/partitions inside the Docker image when this test CI job failed: ... And the listing of /dev/: " Closed !113 - Fix occasional GitLab CI test jobs failures on BlockSpecial unit tests
2023-05-08 12:55:17 -06:00
- 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
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
Print kernel version, etc in GitLab CI (#147) Print the kernel version and supported file systems inside the GNOME GitLab CI jobs as a debugging aid. Kernel version helps identify the CI job runner's distribution to identify kernel features. Supported file systems identifies which ones can be mounted, should that be possible in future. Print supported file systems before and after the tests because checking for support may load additional modules. See calls to Utils::kernel_supports_fs() for: btrfs, jfs, nilfs2 and xfs. Closes #147 - GitLab CI test failure from *.CreateAndGrow/jfs
2021-03-08 08:40:43 -07:00
- fgrep -v nodev /proc/filesystems | sort
Save all files on CI job failure for investigation Since patchset !49 "Add file system interface tests" was merged the GitLab Continuous Integration jobs have sometimes failed executing test_SupportedFilesystems. So on failure save all files from the docker image for 1 week for investigation. Documentation: * Introduction to job artifacts https://gitlab.gnome.org/help/user/project/pipelines/job_artifacts.md * GitLab CI/CD Pipeline Configuration Reference, artifacts https://gitlab.gnome.org/help/ci/yaml/README.md#artifacts
2019-12-03 07:08:06 -07:00
# 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
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 Alpine Linux CI build job (!104) There have been a number of GParted build issues [1][2] recently on Alpine Linux because it uses musl libc [3] which is stricter to POSIX, rather than the GNU C Library (glibc) which has numerous enhancements. Glibc is used by most Linux distributions, including CentOS and Ubuntu already used in the GNOME Continuous Integration jobs. So add a GParted build job on Alpine Linux to catch these issues in future. Uses the docker image of the latest Alpine Linux release. [1] 3d4b1c1e7b33f229efd254fb0cc06660af627ea0 Fix NULL == 0 assumption in call to ped_partition_flag_next() (!100) [2] 45c00927b72319f00855c7feaf4dcf109b3e4414 Use POSIX basename() in BCache_Info.cc (!99) [3] musl libc https://musl.libc.org/ Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 05:01:12 -06:00
# Check GParted can be built and installed on Alpine Linux, CentOS and Ubuntu.
alpine_build:
<<: *alpine_image_definition
<<: *build_stage_definition
Replace CentOS 7 with Rocky Linux 8 in the CI jobs (!124) CentOS reached its end of life on 30 June 2024 and has been discontinued [1][2]. Instead switch to Rocky Linux 8 which is an open-source rebuild of RHEL 8 [3]. [1] What to know about CentOS Linux EOL https://www.redhat.com/en/topics/linux/centos-linux-eol [2] CentOS Linux is going End of Life, What does that mean for me? https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me [3] Rocky Linux https://rockylinux.org/ Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:42:27 -06:00
rocky_build:
<<: *rocky_image_definition
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_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 Alpine Linux CI test job (!104) Closes !104 - Add Alpine Linux CI jobs and resolve label and UUID issues with FAT16/32
2022-06-16 06:47:28 -06:00
# Check GParted unit tests and distcheck pass on Alpine Linux, CentOS and
# Ubuntu.
alpine_test:
<<: *alpine_image_definition
<<: *test_stage_definition
Replace CentOS 7 with Rocky Linux 8 in the CI jobs (!124) CentOS reached its end of life on 30 June 2024 and has been discontinued [1][2]. Instead switch to Rocky Linux 8 which is an open-source rebuild of RHEL 8 [3]. [1] What to know about CentOS Linux EOL https://www.redhat.com/en/topics/linux/centos-linux-eol [2] CentOS Linux is going End of Life, What does that mean for me? https://www.redhat.com/en/blog/centos-linux-going-end-life-what-does-mean-me [3] Rocky Linux https://rockylinux.org/ Closes !124 - Update CI jobs for Ubuntu 24.04 LTS and use Rocky Linux 8
2024-08-05 00:42:27 -06:00
rocky_test:
<<: *rocky_image_definition
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_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