1 |
On 27-11-2018 10:20:52 +0100, Michael Haubenwallner wrote: |
2 |
> On 11/27/2018 09:37 AM, Sam Pfeiffer wrote: |
3 |
> > On Tue, Nov 27, 2018 at 7:20 PM Fabian Groffen <grobian@g.o <mailto:grobian@g.o>> wrote: |
4 |
> > |
5 |
> > > I don't want to depress this entire discussion, but it would be really |
6 |
> > > nice if we could somehow interact with special machines people have at |
7 |
> > > their company or at home. Prefix needs testing on many different |
8 |
> > > machines (non-Linux) which usually don't exist in docker images. |
9 |
> |
10 |
> I second this - and let me add a further aspect here: |
11 |
> What I know from buildbot setup is that the master does provide (mostly shell) |
12 |
> commands to be executed on the slave. This is fine as long as there is limited |
13 |
> visibility for the master. But when a public buildbot master is being hijacked, |
14 |
> it feels too easy to execute malicious commands even on the slave machines. |
15 |
> |
16 |
> So over a buildbot like setup, I would prefer a Jenkins like setup, where the |
17 |
> master does provide only trigger information to slaves. And even more appealing |
18 |
> would be a standalone slave setup, where the master does just receive the build |
19 |
> logs for the public, without access to slave machines at all. |
20 |
|
21 |
So, with this in mind, I've started experimenting, here's my "progress": |
22 |
|
23 |
http://bootstrap.prefix.bitzolder.nl/results/ |
24 |
|
25 |
The idea is to rsync the result after the bootstrap-prefix.sh call to the |
26 |
server. I can have setup to be in an "upload" sense. The current call |
27 |
(which assumes direct access) can be found in the dobootstrap script I |
28 |
currently use to fire off a bootstrap on a platform: |
29 |
|
30 |
http://bootstrap.prefix.bitzolder.nl/dobootstrap (see DOPUBLISH) |
31 |
|
32 |
None of these targets are RAP by the way. I think the current CI is |
33 |
very good at that. |
34 |
|
35 |
By the way, no bootstraps succeeded recently, so that's the goal to get |
36 |
that triggered so we can focus on fixing it. Just being able to pull in |
37 |
the CI success/fail for that would already be a start. |
38 |
|
39 |
Thanks, |
40 |
Fabian |
41 |
|
42 |
-- |
43 |
Fabian Groffen |
44 |
Gentoo on a different level |