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 ).
qtbase
- deploy the configuration into CI for all Qt5 modules, but put it in "" and "
forcesuccess
" modeqt.tests.insignificant
- 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 "" and/or "
forcesuccess
" for all passing modules.qt.tests.insignificant
- feature branches are usually not handled by themselves but rather kept equal to their eventual target branch. For example the "QtBase accessibility-refactor Integration" project should keep the same configuration as "QtBase master Integration". 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":http://testresults.qt.io/qtmetrics/ page.