Sysadmin/Jenkins: Difference between revisions
< Sysadmin
| Line 22: | Line 22: | ||
= Whishlist = | = Whishlist = | ||
* Title: | * Title: Integration with reviewboard | ||
** Reason: | ** Reason: Pre integration testing of patches | ||
** Importance: | ** Importance: Fairly important as it can raise the overall quality of patches | ||
** Contact: | ** Contact: Torgny Nyblom | ||
* Title: Valgrind memcheck runs at unit tests | * Title: Valgrind memcheck runs at unit tests | ||
Revision as of 13:34, 17 March 2012
Here is a collection of stuff that should be done to the jenkins install at http://build.kde.org
A short howto would be nice too...
Issues:
- anongit4: Connection reset by peer on git fetch
- anongit*/jenkins: Poll done before mirror has updated
- Unclear how to support multiple architectures and configurations.
Todo:
- LDAP authentication (tunnel to ldap server needed)
- Windows build slaves (SaroEngels)
- Split "update-build-deps" job into separate jobs
- Add dep-* jobs for all deps compiled once (qt-xxxxx)
- Enable concurrent jobs if one is in the test phase
Misc:
- Pattern for triggering multiple jobs with one poll request, ie build on multiple configurations and/or architectures.
Ideas:
Each project has one job that is triggered from the git hooks, this job then reads a config file and depending on that config triggers the configured builds. Builds are easily triggered using the rest interface. This will solve the issue we have been having with naming convention of the jobs and the possibility to add more configurations and architectures to the build farm.
Whishlist
- Title: Integration with reviewboard
- Reason: Pre integration testing of patches
- Importance: Fairly important as it can raise the overall quality of patches
- Contact: Torgny Nyblom
- Title: Valgrind memcheck runs at unit tests
- Reason: often it is not done before committing the source :)
- Importance: if unit tests are properly designed, this could be an important help to prevent segmentation faults and memory leaks
- Contact: Andreas Cord-Landwehr
- Title: Compilation against all supported versions of Qt
- Reason: On my development machine I only have one version of Qt installed and I can only test my changes with this version. To prevent usage of too new API or detect regressions/changed behavior of Qt with the application (like e..g qDeleteAll in 4.8) the compilations and unit tests should run with old and new versions of Qt.
- Importance: imo I would call this a "should have"
- Contact: Andreas Cord-Landwehr