Re: [Fuego] Dockerfile vs install-debian.sh

<[email protected]>
Newsgroups dev.linux.lists.fuego
Message-ID <OSBPR01MB205391297693A87F79B27EDBD0720@OSBPR01MB2053.jpnprd01.prod.outlook.com>
 -----Original Message-----
> From: sangorrin daniel(サンゴリン ダニエル □SWC◯ACT)
> Hi Georg
> Tim: I have a question of your at the end.

of your -> for you

^^U

> 
> > -----Original Message-----
> > From: Fuego <[email protected]> On Behalf Of
> > Georg Piewald
> > Sent: Monday, July 27, 2020 8:14 PM
> > To: [email protected]
> > Subject: [Fuego] Dockerfile vs install-debian.sh
> >
> > Hi guys,
> >
> > I was just looking into how to install Fuego without a Docker
> > container (since the CHANGELOG says it's possible). Apparently, that's what install-debian.sh is good for (or is there something else, that I
> missed?).
> 
> Yes, I created it in 2019 and it worked at that time. I run it together with LAVA.
> Unfortunately, I haven't been able to maintain it since then for private reasons. Now I am back but I can't spend as much time as I'd like.
> https://bkk19.sched.com/event/Li6u/bkk19-tr08-how-to-integrate-fuego-automated-testing-tool-in-your-ci-loop
> You have the slides there (and the presentation is on youtube)
> 
> > But honestly, this script seems like a halfhearted attempt to me and
> > strongly violates the DRY principle. It is clearly descendant from
> > Dockerfile, but did not evolve with it. Several later modifications in Dockerfile did not make it to install-debian.sh. How do you plan to
> keep these files in sync?
> 
> You are right. This was just a fast prototype to prove a point (that Fuego can work with LAVA, Ktest, Linaro test definitions, and other test
> frameworks) on that conference.
> It is waiting for proper integration and maintenance.
> 
> > I propose to only let install-debian.sh have all the code that sets up
> > the OS and installs all requirements. The Dockerfile instead should do
> > (almost) nothing but execute install-debian.sh.
> 
> Yes, that was my plan as well.
> 
> > An additional benefit of that method is that it will be much easier to also keep Dockerfile.nojenkins in sync with the standard Dockerfile.
> > Because here we have the same problem of lots of copied code, that is
> > slowly drifting apart. We might even not need Dockerfile.nojenkins anymore at all.
> 
> Exactly.
> 
> > I can offer to implement this, unless there are strong objections by anyone.
> 
> That would super awesome. It would be good if you see my video on Youtube or at least read the slides to get a bit of background of what I
> wanted to do with it.
> Also if you have any question about why i did that, or if there is a missing piece of code please let me know.
> 
> Tim: do you agree?
> 
> Best regards,
> Daniel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.