CI Configurations

[toc align_right="yes" depth="2"]

CI Configurations

Test Configurations

These are all the main configurations available. It doesn't mean that all of these are built. Not even for the whole Qt5 project with all its submodules. When building submodules, the set of configurations can be even lower. To see which configuration is built currently, you can go to "QtMetrics":http://testresults.qt.io/qtmetrics/ and see the latest build status.

Also, any module built can overwrite any of these configurations. Luckily there aren't that many of these, but it might affect the outcome compared to what you read below. For specific data concerning your sub module, go see the current status directly from the "source":https://qt.gitorious.org/qtqa/testconfig/trees/master/projects/.

blackberry-armle-v7-qcc_developer-build_Ubuntu_12.04_x64

blackberry-x86-qcc_developer-build_Ubuntu_12.04_x64

linux-android-g++_Ubuntu_12.04_x64

linux-android-g++_Ubuntu_12.04_x64_tablet

linux-android_armeabi-g++_Ubuntu_12.04_x64

linux-arm-gnueabi-g++_Ubuntu_11.10_x86

linux-g++–32_Ubuntu_10.04_x86

linux-g++–32_developer-build_Ubuntu_10.04_x86

linux-g++_bin-pkg-config_Ubuntu_11.10_x86

linux-g++_developer-build_OpenSuSE_13.1_x64

linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64

linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64

linux-g++_no-widgets_Ubuntu_12.04_x64

linux-g++_shadow-build_Ubuntu_11.10_x86

linux-g++_static_Ubuntu_12.04_x64

linux-imx6-armv7a_Ubuntu_12.04_x64

linux-qnx-armv7le_Ubuntu_12.04_x64

linux-qnx-x86_Ubuntu_12.04_x64

macx-clang_OSX_10.7

macx-clang_bin-pkg-config_OSX_10.7

macx-clang_developer-build_OSX_10.9

macx-clang_developer-build_qtnamespace_OSX_10.7

macx-clang_no-framework_OSX_10.8

macx-clang_static_OSX_10.9

macx-ios-clang_OSX_10.9

revdep-qtdeclarative_linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64

revdep-qtdeclarative_linux-g++_shadow-build_Ubuntu_11.10_x86

revdep-qtquickcontrols_linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_12.04_x64

revdep-qtquickcontrols_linux-g++_shadow-build_Ubuntu_11.10_x86

win32-mingw47_developer-build_qtlibinfix_Windows_7

win32-mingw48_developer-build_qtlibinfix_opengl_Windows_7

win32-msvc2010_Windows_7

win32-msvc2010_bin-pkg-config_Windows_7

win32-msvc2010_developer-build_angle_Windows_7

win32-msvc2010_developer-build_qtnamespace_Windows_7

win32-msvc2010_opengl_dynamic_Windows_7

win32-msvc2010_static_Windows_7

win64-msvc2012_developer-build_qtnamespace_Windows_81

win64-msvc2013_developer-build_qtnamespace_Windows_81

wince70embedded-armv4i-msvc2008_Windows_7

winphone-arm-msvc2013_Windows_81

winrt-x64-msvc2013_Windows_81

Partially Deployed Test Configurations

A test configuration is partially deployed if it is being executed for at least some Qt5 modules,
but the results are not (yet) enforcing for all Qt5 modules.

The rolling out of new CI configurations is a staggered process. With respect to Qt5, usually the process is like this:

• build the machines and test environments, do some manual testing (e.g. compilation of <code&gt;qtbase&lt;/code&gt;).
• deploy the configuration into CI for all Qt5 modules, but put it in "<code&gt;forcesuccess&lt;/code&gt;" and "<code&gt;qt.tests.insignificant&lt;/code&gt;" mode
  • this means that compilation is done but the result is discarded, and autotests are run but the results are discarded
• periodically (e.g. daily), check the results of the new configuration. Remove "<code&gt;forcesuccess&lt;/code&gt;" and/or "<code&gt;qt.tests.insignificant&lt;/code&gt;" for all passing modules.
  • feature branches are usually not handled by themselves but rather kept equal to their eventual target branch. For example the "QtBase accessibility-refactor Integration&quot; project should keep the same configuration as "QtBase master Integration&quot;. The reason is that, when we are testing feature branches, part of the reason for performing the test is to determine whether or not the branch is ready for merging. This is undermined if the test configuration is not identical.
• try to solve all the problems in the new configurations or raise tasks for developers to solve them.

One of the goals of adding test configurations in this way is to ensure they are integrated into the system seamlessly and do not disrupt the flow of incoming changes.

To see the current situation of the enforcing compilations or marking tests as insignificant go to the "Qt Metrics&quot;:http://testresults.qt.io/qtmetrics/ page.