Re: [Fuego] How run Fuego tools on a Jenkins slave node

Michael Nazzareno Trimarchi <[email protected]> Sun, 29 Aug 2021 23:37:48 +0200
Newsgroups dev.linux.lists.fuego
Message-ID <CAOf5uw=adqcXa+YJnFaAE_-4nQyqpL7CQdwOO8N0NaNFxEWfeA@mail.gmail.com>
Hi

On Fri, Aug 27, 2021 at 11:10 PM <[email protected]> wrote:
>
>
>
> > -----Original Message-----
> > From: Michael Nazzareno Trimarchi <[email protected]>
> >
> > Hi
> >
> >
> > On Fri, Aug 27, 2021, 6:17 PM <[email protected] <mailto:[email protected]> > wrote:
> >
> >
> >       I just realized you might be asking about how to make the Fuego Jenkins instance a slave
> >       to your already-existing Jenkins instance master.  I have not done a configuration of
> >       Jenkins master/slave like this, but here are some instructions for doing this.
> >       https://baykara.medium.com/part-ii-add-a-jenkins-slave-to-jenkins-master-857ef055122d
> >
> >
> > When I read the code the FTC command run only locally.
>
> The default configuration of ftc is that it run on the host where Fuego is installed, and
> the test programs (that it builds from source), run on the device under test, which
> is usually a remote board accessed via ssh.
>
> > Create pipeline using FTC is not possible.
> I don't understand why a pipeline can't use ftc.  It's just a Linux command line
> tool, like any other. What is the operating system of your Jenkins master?
>
> >What i would like to have is the FTC script
> > on master and the executor on slave.
> When you say "slave" are you referring to a Jenkins process, or the device under test.
> ftc already executes it's tests on the device under test, which is usually a separate
> machine from where Fuego and ftc are installed.
>
> >
> > Do I need to split the logic?
> I think the logic is already split, but I'm still not sure I understand your use case.
>
> Please see the architecture diagram on this page:
> http://fuegotest.org/wiki/Architecture
>
> I guess my question is: Where is your Jenkins master running?  It is on the same machine
> as the Fuego installation?
>
> >
> > I have already a complex multislave configuration but i have a lot of hardware and slave but i decided to go to Fuego as regression testing
> > machine
>
> ftc doesn't talk to a Jenkins slave.  It is usually executed by a Jenkins slave.
> However, in the default configuration of the instance of Jenkins integrated
> into the docker container, the slaves are processes that run on the same
> host as the Jenkins master process.  There is one slave (aka 'node') allocated
> for each board installed in the system.  This is done with 'ftc add-node'.
> When the master executes a job, it is assigned to the slave/node that
> corresponds to the board related to that node.  That slave runs ftc, and
>
> ftc (usually) uses ssh to directly access and manage the device under test
> (the 'target board' in the Architecture Diagram).

This is what I understand. I can build a docker image just using the fuego.
From a jenkins pipeline I can use docker.inside("fuego") docker image.
From fuego docker I can launch tools from the slave to the hardware
connected to the slave
that can offer me ssh or any kind of connection. I notice that you
have a slave.jar
in your bitbucket. What is it?

jenkins_master\->slave1 -> hw1,hw2
                        \->slave2 -> hw3

Michael


>
> I'm afraid I still don't understand the configuration you'd like to use.
>
>  -- Tim
>
> >
> >       > -----Original Message-----
> >       > From: Fuego <[email protected] <mailto:[email protected]> > On Behalf Of
> > [email protected] <mailto:[email protected]>
> >       >
> >       > > -----Original Message-----
> >       > > From: Fuego <[email protected] <mailto:[email protected]> > On Behalf Of
> > Michael Nazzareno Trimarchi
> >       > >
> >       > > Hi
> >       > >
> >       > > I have already a ci setup but i would like to use Fuego and run script on slave and get results on master node. Is there a way to
> > configure
> >       > it?
> >       >
> >       > I believe so.  Other Fuego users have used Fuego with CI systems other than the
> >       > default one included (the Jenkins instance inside the Fuego docker container).
> >       >
> >       > You can perform tests using Fuego, using the 'ftc' command line tool.
> >       >
> >       > The default installation of Fuego creates a docker container where Fuego core
> >       > scripts and Jenkins are installed.  You can run 'ftc' from inside this container
> >       > (which is where the included Jenkins will execute test jobs from), or from outside
> >       > the container, from the command line.
> >       >
> >       > When you install Fuego, you have the option to build the container without Jenkins
> >       > (so it just consist of the build environment for the tests, and the Fuego core scripts).
> >       > See http://fuegotest.org/wiki/Installing_Fuego#without_Jenkins for a description
> >       > of the install option used for this.
> >       >
> >       > By way of example, when Fuego is run with Jenkins, it creates Jenkins jobs with
> >       > the following command sequence for the "build" attribute (this example is for
> >       > the test Functional.hello_world):
> >       >
> >       >
> >       > #logging areas=pre_test,pre_check,build,makepkg,deploy,snapshot,run,
> >       > #    post_test,processing, parser,criteria,charting
> >       > #logging levels=debug,verbose,info,warning,error
> >       > #export FUEGO_LOGLEVELS="run:debug,parser:verbose"
> >       > export FUEGO_CALLER="jenkins"
> >       > ftc run-test -b $NODE_NAME -t Functional.hello_world -s default \
> >       >     --timeout 6m \
> >       >     --reboot false \
> >       >     --rebuild false \
> >       >     --precleanup true \
> >       >     --postcleanup true
> >       >
> >       > If the environment variable FUEGO_CALLER is set to "jenkins", then ftc and the
> >       > core test system perform additional steps with the integrated
> >       > Jenkins system (such as augmenting the Jenkins build with pointers to Fuego
> >       > test artifacts, so they are accessible in the Jenkins interface).  However, if you
> >       > are running Jenkins somewhere else (not in the
> >       > Fuego container), then I think the jobs and build data will not be in the
> >       > expected directories for Fuego to operate on.  So this aspect of Fuego/Jenkins
> >       > integration would be lost (or you would have to recreate it).
> >       >
> >       > If FUEGO_CALLER is not set, then ftc and the core test system will just output
> >       > the test execution to stdout, and deposit test artifacts in the fuego-rw/logs
> >       > directory.  Build artifacts (e.g. the test program source and build directories
> >       > are under fuego-rw/buildzone).
> >       >
> >       > See 'ftc run-test help' for information about the arguments used in the above
> >       > example ftc invocation. Not all of these arguments are required (in fact, most
> >       > of those will default to the values shown above, but they are placed in the Jenkins
> >       > job definition to allow users to more easily remember and edit them for a particular job.)
> >       >
> >       > If I had a BeagleBone Black board in my lab, named 'bbb', I could execute
> >       > a test at the command line with: "ftc run-test -b bbb -t hello_world"
> >       >
> >       > By default, visualization of Fuego results (tables and plots) are prepared
> >       > for use in the integrated Jenkins interface.  However, you can also generate reports
> >       > in various formats, that might be useful with your Jenkins (or whatever other CI
> >       > system one might use).
> >       >
> >       > Look at the options for 'ftc gen-report', particularly the 'txt', 'html', or 'csv' output
> >       > formats, which might be import-able into your CI system, for generating your
> >       > own results data displays.
> >       >
> >       > The graphical results (measure plots) for Benchmark data is generated in a json
> >       > format which is interpreted by a javascript module called 'mod.js', which uses
> >       > a graphing module called 'flot' that is installed as a Jenkins plugin.  'flot' and 'mod.js'
> >       > might be usable with other CI systems that have a web-based user interface
> >       > (as they are just javascript (well, jquery)) but it would take some work to perform
> >       > that integration.
> >       >
> >       > It sounds like part of your question is about how the host/target relationship is
> >       > handled in Fuego. By default, a Fuego test runs on a host, and the test programs
> >       > are actually transferred to the device under test and executed there, during test
> >       > execution.  However, some Fuego users install the Fuego core system on the actual
> >       > device under test, and execute it locally.  In this case, the remote aspect of the
> >       > test would be handled by the calling CI system, not by Fuego.
> >       >
> >       > Normally, with the integrated version of Jenkins (the one in the Fuego docker container),
> >       > there is a slave used that is assigned to each node (board).  This ends up serializing
> >       > the access to that board.  But this slave runs on the host machine, where Jenkins
> >       > and Fuego are installed.  Are you asking about executing a Jenkins slave on a remote
> >       > machine (perhaps the device under test), and having Fuego installed there?
> >       >
> >       > Hopefully the information above  is helpful.
> >       >
> >       > I'm not sure exactly what you are asking, but please let me know if you need more
> >       > information.  I am happy to discuss your configuration, and see if Fuego would work
> >       > for you.
> >       >  -- Tim
> >       >
> >       >
> >       > _______________________________________________
> >       > Fuego mailing list
> >       > [email protected] <mailto:[email protected]>
> >       > https://lists.linuxfoundation.org/mailman/listinfo/fuego
> >
>


-- 
Michael Nazzareno Trimarchi
Co-Founder & Chief Executive Officer
M. +39 347 913 2170
[email protected]
__________________________________

Amarula Solutions BV
Joop Geesinkweg 125, 1114 AB, Amsterdam, NL
T. +31 (0)85 111 9172
[email protected]
www.amarulasolutions.com