1 |
Hi folks, |
2 |
|
3 |
This week, I have moved on to the next part of my project: an ebuild |
4 |
testing framework. For sophisticated ebuilds with many dependencies |
5 |
and a lot of USE flags, a framework which facilitates automated ebuild |
6 |
installation tests can be very useful. Such a testing framework can |
7 |
also integrate with a CI service so the tests can be run periodically |
8 |
and automatically, reminding developers of ebuild breakages early. |
9 |
|
10 |
Maintainers of ebuilds for Java packages -- especially those ebuilds |
11 |
in the Spark overlay -- might want to test installing those ebuilds |
12 |
periodically and with different USE flag configurations. To start |
13 |
with, Java packages usually have multiple dependencies, and successful |
14 |
installation of all those dependencies is necessary for successful |
15 |
installation of such a Java package itself. Some packages in the |
16 |
Spark overlay depend on ebuilds in ::gentoo, but chances are the |
17 |
latter set of ebuilds get updated or removed, preventing those ebuilds |
18 |
in the overlay from being merged properly. As a matter of fact, some |
19 |
ebuilds in the Spark overlay are already non-installable due to |
20 |
removal of some Java packages from ::gentoo. In this case, if there |
21 |
is a set of ebuild installation tests that run every day or every |
22 |
week, then problems like this can be discovered as soon as they |
23 |
emerge. Besides dependencies, USE flags are another type of |
24 |
parameters that can determine whether an ebuild can be installed |
25 |
because a USE flag can affect the list of dependencies and/or how the |
26 |
ebuild is compiled and installed. Many ebuilds in the Spark overlay |
27 |
have a 'binary' USE flag (just like any ebuild created by |
28 |
java-ebuilder) which installs a pre-built binary JAR from Maven |
29 |
Central when enabled. Some of the ebuilds can be installed with |
30 |
USE="binary" but not with USE="-binary" due to errors in Java source |
31 |
compilation. The same ebuild should be tested with both of the USE |
32 |
flag configurations if the goal is to support both binary and source |
33 |
installation. |
34 |
|
35 |
My original plan with regards to ebuild testing is to use an existing |
36 |
solution called ebuildtester [1], which is a program that can install |
37 |
a specified package in a stage3 Docker container. After doing some |
38 |
research on it, I found that it cannot satisfy some of my ebuild |
39 |
testing requirements for the Kotlin ebuilds I had created in the |
40 |
previous weeks at least. I would like to fully customize USE flag |
41 |
settings just like how I could specify USE flag settings in |
42 |
/etc/portage/package.use, but ebuildtester only supports a global USE |
43 |
flag setting and USE configuration for the package being tested |
44 |
itself, so the granularity is too coarse. My Kotlin ebuilds need to |
45 |
be installed with multiple emerge commands, which is quite uncommon |
46 |
for ebuilds to be honest, but with ebuildtester, it does not seem to |
47 |
be possible to run more than one emerge command. However, I still |
48 |
liked the idea of testing ebuild installation in a Docker container, |
49 |
so based on ebuildtester's concept, I created my own tool that tests |
50 |
ebuilds in a container: ebuild-commander [2]. This tool does not take |
51 |
an atom to be installed as input; instead, it takes a list of commands |
52 |
to execute in the container (hence the name "ebuild-commander"). It |
53 |
also supports copying a specified directory's contents to the |
54 |
container's /etc/portage, allowing full customization on Portage |
55 |
settings in ebuild tests. ebuild-commander is like a rewrite of |
56 |
ebuildtester strived to allow full control over the ebuild test |
57 |
execution with a simpler interface. |
58 |
|
59 |
Automated and periodic ebuild testing with ebuild-commander has now |
60 |
been set up for my fork of the Spark overlay [3]. I have only created |
61 |
two test cases for my Kotlin ebuilds at this point, but more tests can |
62 |
be added later quickly and easily. At this point, I am planning to |
63 |
implement a mechanism to automatically compute a minimal set of |
64 |
packages that need to be specified in arguments to emerge in order to |
65 |
install all packages in the Spark overlay at least once. Because a |
66 |
test case can take a very long time to run, the tests are configured |
67 |
to run once a day only instead of on every new commit. |
68 |
|
69 |
That is all for this week. See you in the next weekly report! |
70 |
|
71 |
Have a good week, |
72 |
Leo |
73 |
|
74 |
[1]: https://github.com/nicolasbock/ebuildtester |
75 |
[2]: https://github.com/Leo3418/ebuild-commander |
76 |
[3]: https://github.com/Leo3418/spark-overlay/actions/workflows/docker.yml |