AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
5ec53e6a11
gtk2/.gitlab-ci/run-tests.sh

35 lines
778 B
Bash
Raw Normal View History

ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
#!/bin/bash
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
set +x
set +e
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
srcdir=$( pwd )
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
builddir=$1
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
export GDK_BACKEND=x11
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
xvfb-run -a -s "-screen 0 1024x768x24" \
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
meson test -C ${builddir} \
--print-errorlogs \
ci: Add missing newline escape Otherwise we're going to run the accessibility test suite, and it's going to fail.
2020-01-29 11:31:00 +00:00
--suite=gtk \
ci: Refactor the CI pipeline We should have a single job for building both static and shared versions of GTK. On the other hand, having a separate job for the release build would be a plus. Additionally, we shouldn't use an opaque script to build GTK; the only step in the process that requires hand-holding is running the tests suites under Xvfb, and having the build options visible from the YAML file gives us a better idea of what kind of build we're running.
2020-01-29 09:35:10 +00:00
--no-suite=gtk:a11y
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
# Store the exit code for the CI run, but always
# generate the reports
exit_code=$?
ci: Fix linking of the CI assets in the report The report is relative to the build directory, and so are the generated assets.
2020-02-12 18:03:48 +00:00
cd ${builddir}
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
$srcdir/.gitlab-ci/meson-junit-report.py \
--project-name=gtk \
--job-id="${CI_JOB_NAME}" \
ci: Fix linking of the CI assets in the report The report is relative to the build directory, and so are the generated assets.
2020-02-12 18:03:48 +00:00
--output=report.xml \
meson-logs/testlog.json
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
$srcdir/.gitlab-ci/meson-html-report.py \
--project-name=gtk \
--job-id="${CI_JOB_NAME}" \
ci: Fix linking of the CI assets in the report The report is relative to the build directory, and so are the generated assets.
2020-02-12 18:03:48 +00:00
--reftest-output-dir="testsuite/reftests/output" \
--output=report.html \
meson-logs/testlog.json
ci: Generate the report for the release builds We are going to need to hide the report generation into the test runner script, as we want the job to produce the reports even in case of failure, instead of bailing out immediately.
2020-01-29 13:36:23 +00:00
exit $exit_code
Reference in New Issue Copy Permalink