CI Pipelines
Steven Robbins
steve at sumost.ca
Sun Sep 18 15:44:12 BST 2022
On Sunday, September 18, 2022 9:27:46 A.M. CDT Maik Qualmann wrote:
> The timeouts are not relevant, the image quality sorters require more than 1
> minute and are therefore terminated.
The logs suggest that the timeout IS the cause of the test failure:
98% tests passed, 1 tests failed out of 48
Total Test time (real) = 158.09 sec
The following tests FAILED:
14 - digikam-detectgeneral_goodimage_utest (Timeout)
Errors while running CTest
XIO: fatal IO error 4 (Interrupted system call) on X server ":90"
after 548 requests (548 known processed) with 0 events remaining.
## Tests failed
Uploading artifacts for failed job
Note the last line that says "... for failed job". In contrast, when the
tests pass, the output is:
100% tests passed, 0 tests failed out of 48
Total Test time (real) = 203.34 sec
## RUNNING: gcovr -x --output="CoberturaLcovResults.xml" -e "_build/.*" -r "/
builds/graphics/digikam"
XIO: fatal IO error 4 (Interrupted system call) on X server ":90"
after 548 requests (548 known processed) with 0 events remaining.
## CI Run Completed Successfully!
Uploading artifacts for successful job
And even when the tests succeed, there are still warnings and errors about
cppcheck.json. I think these must be ignored as very last line is "Job
succeeded":
## CI Run Completed Successfully!
Uploading artifacts for successful job
Uploading artifacts...
JUnitTestResults.xml: found 1 matching files and directories
Uploading artifacts as "junit" to coordinator... 201 Created id=472093
responseStatus=201 Created token=Az-zAzNL
Uploading artifacts...
WARNING: cppcheck.json: no matching files. Ensure that the artifact path is
relative to the working directory
ERROR: No files to upload
Uploading artifacts...
CoberturaLcovResults.xml: found 1 matching files and directories
Uploading artifacts as "cobertura" to coordinator... 201 Created id=472093
responseStatus=201 Created token=Az-zAzNL
Cleaning up project directory and file based variables
Job succeeded
> The reason for the failure is the last
> output:
>
> Uploading artifacts...
> WARNING: cppcheck.json: no matching files. Ensure that the artifact path is
> relative to the working directory ERROR: No files to upload
> Uploading artifacts...
> WARNING: CoberturaLcovResults.xml: no matching files. Ensure that the
> artifact path is relative to the working directory ERROR: No files to
> upload
>
> Cleaning up project directory and file based variables
> 00:02
> ERROR: Job failed: exit code 1
>
> Maik
>
> Am Sonntag, 18. September 2022, 15:31:28 CEST schrieb Steven Robbins:
> > On Saturday, September 17, 2022 11:33:06 P.M. CDT Gilles Caulier wrote:
> > > Hi,
> > >
> > > As i can see the dysfunction come from ImageMagick backend called by
> > > DMetadata parser.
> > >
> > > Typically, we have more than one metadata parser as Exiv2, ffmpeg,
> > > libraw, ExifTool, and Imagegic.
> > > This last one is less robust than the previous one, and depending of
> > > IM version installed on the CI computer, it can crash at run time.
> >
> > Are you saying that the version of ImageMagick on the CI builder has
> > changed a week ago? And that the failing code is within the ImageMagick
> > library itself?
> >
> > The passing CI run claims it did NOT find Image Magick (but did find the
> > image magic version??):
> >
> > -- Could NOT find ImageMagick (missing: ImageMagick_Magick++_LIBRARY)
> > (found version "7.1.0-47")
> > -- ImageMagick_FOUND: FALSE
> > -- ImageMagick_VERSION_STRING: 7.1.0-47
> > -- ImageMagick_EXECUTABLE_DIR: /usr/bin
> > -- ImageMagick_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_LIBRARIES: /usr/lib64/
> > libMagickCore-7.Q16HDRI.so;/usr/lib64/libMagickWand-7.Q16HDRI.so
> > -- ImageMagick_DEFINITIONS: -
DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> > -- ImageMagick_Magick++_INCLUDE_DIRS:
> > -- ImageMagick_Magick++_LIBRARY:
> > ImageMagick_Magick++_LIBRARY-NOTFOUND
> > -- ImageMagick_Magick++_DEFINITIONS:
> > -- ImageMagick_MagickCore_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_MagickCore_LIBRARY: /usr/lib64/
> > libMagickCore-7.Q16HDRI.so
> > -- ImageMagick_MagickCore_DEFINITIONS: -DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> > -- ImageMagick_MagickWand_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_MagickWand_LIBRARY: /usr/lib64/
> > libMagickWand-7.Q16HDRI.so
> > -- ImageMagick_MagickWand_DEFINITIONS: -DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> >
> >
> > Today ImageMagick *IS* found (with same version):
> >
> > -- Found ImageMagick: /usr/lib64/libMagick++-7.Q16HDRI.so (found version
> > "7.1.0-47")
> > -- ImageMagick_FOUND: TRUE
> > -- ImageMagick_VERSION_STRING: 7.1.0-47
> > -- ImageMagick_EXECUTABLE_DIR: /usr/bin
> > -- ImageMagick_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_LIBRARIES: /usr/lib64/libMagick+
> > +-7.Q16HDRI.so;/usr/lib64/libMagickCore-7.Q16HDRI.so;/usr/lib64/
> > libMagickWand-7.Q16HDRI.so
> > -- ImageMagick_DEFINITIONS: -
DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> > -- ImageMagick_Magick++_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_Magick++_LIBRARY: /usr/lib64/libMagick+
+-7.Q16HDRI.so
> > -- ImageMagick_Magick++_DEFINITIONS: -DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> > -- ImageMagick_MagickCore_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_MagickCore_LIBRARY: /usr/lib64/
> > libMagickCore-7.Q16HDRI.so
> > -- ImageMagick_MagickCore_DEFINITIONS: -DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> > -- ImageMagick_MagickWand_INCLUDE_DIRS: /usr/include/ImageMagick-7
> > -- ImageMagick_MagickWand_LIBRARY: /usr/lib64/
> > libMagickWand-7.Q16HDRI.so
> > -- ImageMagick_MagickWand_DEFINITIONS: -DMAGICKCORE_HDRI_ENABLE=1;-
> > DMAGICKCORE_QUANTUM_DEPTH=16
> >
> >
> > Maybe that's the difference?
> >
> > Weirdly, the most recent CI run [1] has just one failure -- and this time
> > due to a timeout. No bad memory access -- was it addressed?
> >
> > [1] https://invent.kde.org/graphics/digikam/-/jobs/483635/raw
> >
> > -Steve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20220918/5767ed71/attachment-0001.sig>
More information about the Digikam-devel
mailing list