| 1 |
Hi all, |
| 2 |
|
| 3 |
This week, the aim was to experiment with ebuilds and eclasses to finalize |
| 4 |
the way the test scripts would be added to the portage tree. |
| 5 |
|
| 6 |
These test scripts are ways to test a package for basic functionality, to |
| 7 |
make sure that the merge step has been properly executed. The automated |
| 8 |
build system should be able to run these scripts as a part of routine |
| 9 |
builds, in order to test the packages for stability, just as an Arch tester |
| 10 |
would. |
| 11 |
|
| 12 |
Under current implementation, the plan is to create a new eclass, say |
| 13 |
arch-tests.eclass, that would define a new function that looks for tests in |
| 14 |
the files subdirectory, and runs them if found. This function would be |
| 15 |
called if a certain use flag is set, and would be called from pkg_postinst. |
| 16 |
|
| 17 |
For packages that can share the same tests, like python packages, the |
| 18 |
common eclass for them, for example python-r1 could contain a common test |
| 19 |
(Like one that just imports the package and make sure that succeeds). This |
| 20 |
function would be looked for, by the arch-tests.eclass function, and be |
| 21 |
executed if present. |
| 22 |
|
| 23 |
Another task for this week was to start employing an external database for |
| 24 |
storage to make sure that multiple servers can use input output securely |
| 25 |
without data races. |
| 26 |
This is still in progress, and will carry on to this week. |
| 27 |
|
| 28 |
Regards, |
| 29 |
Pallav |
Archives