Sysadmin/Jenkins: Difference between revisions
< Sysadmin
No edit summary |
No edit summary |
||
| Line 16: | Line 16: | ||
= Ideas: = | = 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. | 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: | |||
** Reason: | |||
** Importance: | |||
** Contact: | |||
Revision as of 14:24, 12 February 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
Todo:
- LDAP authentication (tunnel to ldap server needed)
- Windows build slaves (SaroEngels)
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:
- Reason:
- Importance:
- Contact: