1 |
On 2/3/19 11:55 AM, Fabian Groffen wrote: |
2 |
> On 27-11-2018 10:20:52 +0100, Michael Haubenwallner wrote: |
3 |
>> On 11/27/2018 09:37 AM, Sam Pfeiffer wrote: |
4 |
>>> On Tue, Nov 27, 2018 at 7:20 PM Fabian Groffen <grobian@g.o <mailto:grobian@g.o>> wrote: |
5 |
>>> |
6 |
>>>> I don't want to depress this entire discussion, but it would be really |
7 |
>>>> nice if we could somehow interact with special machines people have at |
8 |
>>>> their company or at home. Prefix needs testing on many different |
9 |
>>>> machines (non-Linux) which usually don't exist in docker images. |
10 |
>> |
11 |
>> I second this - and let me add a further aspect here: |
12 |
>> What I know from buildbot setup is that the master does provide (mostly shell) |
13 |
>> commands to be executed on the slave. This is fine as long as there is limited |
14 |
>> visibility for the master. But when a public buildbot master is being hijacked, |
15 |
>> it feels too easy to execute malicious commands even on the slave machines. |
16 |
>> |
17 |
>> So over a buildbot like setup, I would prefer a Jenkins like setup, where the |
18 |
>> master does provide only trigger information to slaves. And even more appealing |
19 |
>> would be a standalone slave setup, where the master does just receive the build |
20 |
>> logs for the public, without access to slave machines at all. |
21 |
> |
22 |
> So, with this in mind, I've started experimenting, here's my "progress": |
23 |
> |
24 |
> http://bootstrap.prefix.bitzolder.nl/results/ |
25 |
|
26 |
Nice! |
27 |
|
28 |
> The idea is to rsync the result after the bootstrap-prefix.sh call to the |
29 |
> server. I can have setup to be in an "upload" sense. The current call |
30 |
> (which assumes direct access) can be found in the dobootstrap script I |
31 |
> currently use to fire off a bootstrap on a platform: |
32 |
> |
33 |
> http://bootstrap.prefix.bitzolder.nl/dobootstrap (see DOPUBLISH) |
34 |
|
35 |
So I'm wondering how to enable myself to provide logs for some more CHOSTs. |
36 |
What about rsync + ssh via pecker? |
37 |
|
38 |
> None of these targets are RAP by the way. I think the current CI is |
39 |
> very good at that. |
40 |
|
41 |
Absolutely. However, it would be nice if we could integrate the Linux/RAP |
42 |
results into this overwiew as well - besides the Linux/Guest ones, even |
43 |
if they share the same CHOST... |
44 |
|
45 |
Also, just've found https://wiki.gentoo.org/wiki/Prefix/tested where the |
46 |
'Last tried' column values seem outdated - maybe CI builds can provide |
47 |
more recent dates there as well. |
48 |
|
49 |
> By the way, no bootstraps succeeded recently, so that's the goal to get |
50 |
> that triggered so we can focus on fixing it. Just being able to pull in |
51 |
> the CI success/fail for that would already be a start. |
52 |
|
53 |
FWIW, I've created a gentoo-prefix project with Azure pipelines, but their |
54 |
6 hours limit is too small for Prefix on Cygwin. So I've added my own |
55 |
Windows VM there: https://dev.azure.com/gentoo-prefix/ci-builds/_build |
56 |
However, I'm not sure if I should keep that for security concerns... |
57 |
|
58 |
BTW, Cygwin 3.0.0-0.8 does have the fork() that works for Gentoo Prefix! |
59 |
|
60 |
Thanks! |
61 |
/haubi/ |