1 |
Dear Pallav, |
2 |
|
3 |
how about using a dedicated eclass for arch-testing? |
4 |
|
5 |
E.g., you might provide a function in some eclass |
6 |
that only runs when called from pkg_postinst [1] |
7 |
phase AND when some configuration option is set. |
8 |
|
9 |
Then a maintainer / arch tester might provide |
10 |
the tests inside the ebuild directory, e.g., |
11 |
inside a hidden sub-directory .arch-tests or |
12 |
something like that, include your eclass inside |
13 |
the ebuild and call your test-function from pkg_postinst |
14 |
or something like that... |
15 |
|
16 |
[1] |
17 |
https://devmanual.gentoo.org/ebuild-writing/functions/pkg_postinst/index.html |
18 |
|
19 |
|
20 |
Best wishes, |
21 |
|
22 |
|
23 |
Harald. |
24 |
|
25 |
Harald Weiner |
26 |
Institute of Applied Geometry |
27 |
|
28 |
Johannes-Kepler-Universität |
29 |
Altenberger Straße 69 |
30 |
A-4040 Linz |
31 |
harald.weiner@×××.at |
32 |
http://www.ag.jku.at |
33 |
|
34 |
On 05/19/2016 09:45 AM, Pallav Agarwal wrote: |
35 |
> This is a continuation of "[gentoo-dev] Proposal for changes for the |
36 |
> next EAPI |
37 |
> version" thread. Since the former subject isn't very relevant anymore. |
38 |
> |
39 |
> Target: |
40 |
> A place to provide scripts that can be used by an automated |
41 |
> arch-tester bot to |
42 |
> stabilize Gentoo packages. These scripts can be as simple as a one liner |
43 |
> |
44 |
> `python -c "import module"` |
45 |
> |
46 |
> for example in case of a python module. Or a little complex, for |
47 |
> example to test |
48 |
> different features in case of different USE flags. |
49 |
> The main target is to alleviate the problems and unreliability from |
50 |
> ARCH Testing |
51 |
> and to more thoroughly and automatically test packages. |
52 |
> |
53 |
> 1 - Some important factors to consider from the previous thread: |
54 |
> a) This must be run POST-MERGE so that problems after merging can be |
55 |
> detected |
56 |
> b) It should be hopefully scalable in both directions - similar tests |
57 |
> for multiple packages |
58 |
> - different tests for different versions of same package. |
59 |
> c) If a users want, they should be able to run these tests too (If |
60 |
> they do, bug reports |
61 |
> collected will be very valuable. |
62 |
> d) Most common opinion was to not have an EAPI change unless this |
63 |
> gains enough |
64 |
> use or demand. |
65 |
> e) If implemented as a part of ebuild, it can have all benefits of an |
66 |
> ebuild syntax. |
67 |
> Different versions of a package can have different test scripts. Test |
68 |
> code part can |
69 |
> have its own conditional runtime dependencies (only to take effect IF |
70 |
> testing is on). |
71 |
> Also, it can have specific parts of test run or not dependent on USE |
72 |
> flags enabled. |
73 |
> |
74 |
> 2 - Some suggested solutions |
75 |
> a) The original proposed solution: |
76 |
> To have an extra phase ci_test() or something similar that would be |
77 |
> run ONLY when |
78 |
> emerge is called with ci-test option. That way rest of the ebuild |
79 |
> doesn't have to change, |
80 |
> and for normal users, this wouldn't run unless they explicitly want it to. |
81 |
> |
82 |
> PROS: |
83 |
> i) Full use of ebuild syntax |
84 |
> ii) Users can also use. |
85 |
> CONS: |
86 |
> i) Requires EAPI change |
87 |
> ii) Burdens the ebuild with more stuff |
88 |
> iii) Existing ebuilds need to be changed (one more revision per ebuild) |
89 |
> |
90 |
> b) Having an extra global USE flag "ci_test" and putting test code in |
91 |
> pkg_postinst |
92 |
> phase under `if use ci_test` condition. |
93 |
> |
94 |
> PROS: |
95 |
> i) Full use of ebuild syntax |
96 |
> ii) Users can enable ci-test too |
97 |
> iii) Changes to current ebuild standard is negligible |
98 |
> CONS: |
99 |
> i) Burdens the ebuild with more stuff |
100 |
> ii) Existing ebuilds need to be changed (one more revision per ebuild) |
101 |
> |
102 |
> c) Creating a Gentoo Overlay with ebuilds which do test packages. And |
103 |
> the testing |
104 |
> script would be part of the pkg_postinst existing function. |
105 |
> For example, overlay could have a package dev-python/numpy-ci-test with: |
106 |
> ``` |
107 |
> DEPEND="dev-python/numpy" |
108 |
> pkg_postinstall() { |
109 |
> python -c "import numpy; numpy.test()" || die "failed" |
110 |
> } |
111 |
> ``` |
112 |
> as it's content. |
113 |
> |
114 |
> PROS: |
115 |
> i) No change to existing ebuilds or EAPI |
116 |
> ii) Can almost use all benefits of ebuild syntax |
117 |
> iii) Anybody can submit tests for ebuilds to the corresponding ebuild |
118 |
> on overlay |
119 |
> iv) Eclasses can define CI tests for multiple packages at once |
120 |
> CONS: |
121 |
> i) Users will almost never use an overlay just for testing |
122 |
> ii) Maintainer will have to submit one script for the portage tree and |
123 |
> one for the overlay. |
124 |
> Many maintainers would prefer to skip that. |
125 |
> iii) Ebuild names need to be different from the ones in portage tree, |
126 |
> so the process isn't |
127 |
> transparent anymore. We first need to check if -ci-test package exists |
128 |
> or not. |
129 |
> |
130 |
> |
131 |
> Any more suggestions/comments/methods are invited. |
132 |
> |
133 |
> --- |
134 |
> Regards, |
135 |
> Pallav |