| 1 |
On Thu, Dec 4, 2014 at 2:36 PM, Alec Ten Harmsel |
| 2 |
<alec@××××××××××××××.com> wrote: |
| 3 |
> |
| 4 |
> It'd be cool if Gentoo had some sort of automated workflow (with |
| 5 |
> Jenkins, buildbot, whatever) like this: |
| 6 |
> |
| 7 |
> 1. Receive pull request |
| 8 |
> 2. Detect changed ebuild |
| 9 |
> 3. test ebuild with etest |
| 10 |
> |
| 11 |
> This will take a lot of work to set up, and depending on how my workload |
| 12 |
> is next semester, I would love to help out as much as possible. |
| 13 |
> |
| 14 |
|
| 15 |
I've wondered the same thing, and maybe after sufficient bikeshedding |
| 16 |
something like this would be a good GSoC project as well. Running |
| 17 |
repoman is another possibility. |
| 18 |
|
| 19 |
One trick is that a pull request could impact multiple packages |
| 20 |
(eclass changes, dependency updates, etc). In these cases running |
| 21 |
repoman probably adds more value than full tests. Either way there |
| 22 |
will potentially be a high cost to do the testing, which could create |
| 23 |
a backlog if we queue things up (not queuing things creates other |
| 24 |
problems). Repoman false-alarms is another potential issue with this. |
| 25 |
|
| 26 |
So, it may not be a trivial thing to do, but some kind of CI workflow |
| 27 |
would be a wonderful thing to have. |
| 28 |
|
| 29 |
-- |
| 30 |
Rich |
Archives