| 3 | | Also, the framework should allow to run the system image in a simulator, run automated regression tests inside HelenOS and gather the result. A good way to communicate between the host and the guest system is a virtual disk. For this we need filesystem unmounting (#79). |
| | 3 | Details:: |
| | 4 | The framework would periodically build the newest revision of the HelenOS sources for all supported targets and report back potential build problems. The periodicity should be configurable to happen after each integration or in some fixed intervals such as on the nightly basis. Depending on the periodicity, the framework should be able to either point to the exact changeset which introduced the breakage or at least say the breakage was introduced between revisions X and Y. |
| | 5 | |
| | 6 | The second major role of the framework would be to consecutively run the built system images in a suitable simulator such as Qemu, run automated regression tests inside HelenOS and store the results on a disk from where they could be read by the framework and published via a web interface. As in the previous case, the framework should be able to figure out what revision made some testcase fail. |
| | 7 | |
| | 8 | This project depends on: |
| | 9 | #124 Hands-off configure/build |
| | 10 | |
| | 11 | What Gains and Benefits will this bring?:: |
| | 12 | With the help of a tool like this, we should be able to catch most regressions much earlier than we do now. A person who neglects to test his changes on all supported platforms will automatically learn about the problem immediately or the other day at the latest. |
| | 13 | |
| | 14 | Difficulty:: |
| | 15 | medium |
| | 16 | |
| | 17 | Required skills:: |
| | 18 | A successful applicant should be able to integrate several products together. |
| | 19 | |
| | 20 | Documentation:: |
| | 21 | |
