[Fuego] [PATCH] Fuego Release Test Repository

Tim.Bird at sony.com Tim.Bird at sony.com
Tue Feb 20 01:25:34 UTC 2018

> -----Original Message-----
> From: Gustavo Sverzut Barbieri
> On Fri, Feb 16, 2018 at 7:42 PM, Guilherme Campos Camargo
> <guicc at profusion.mobi> wrote:
> ...
> > Also, it's important to note that this patch represents a sort of
> > paradigm shift in the way that tests are added to Fuego, given that:
> > - The software requirements are being installed through a Dockerfile
> >   that extends fuego-base.
> > - The test routines/plans and the new boards are moved to Fuego during
> >   build time, acting almost as an "overlay".
> > For that reason, it's imperative that current users/contributors provide
> > their feedback regarding this new approach before we move on. Also,
> > since I just started contributing with and using fuego, it's likely that
> > I missed something, specially related to Fuego usability. So please,
> > kindly add your comments and correct me if so.
> Tim, I discussed this with Guilherme and we'll formalize a proposal
> around the spec.json file, something along the lines:
> 1) test specify the debian repositories, packages and even gpg/keys
> (for repos). Instead of always adding the packages to the container,
> either by modifying the official docker image (as done before) or
> creating an overlay (as done by Guilherme), Fuego would make sure the
> repositories are added and packages are added prior to executing the
> tests.

Since I haven't been able to run the release-test yet, this is also going
over my head.

What problem is this solving?

Is this for a test to specify additional packages for the base distribution
in the docker container, that the test needs on the host?
Or is it referring to a new -dev package used for building the software
for the target (but again, something that needs to be in the
docker container, but is part of the toolchain)?

Would this be used for something like:
 lib-cairo-dev, or netperf-server?

> JSON object would look like:
>    "packages-dependencies": {
>        "repositories": ["deb https://download.docker.com/linux/debian
> jessie"],
>        "keys": ["https://download.docker.com/linux/debian/gpg"],
>        "packages": ["docker-ce", "libxpto-dev"],
>    }
> Which would manage /etc/apt/sources.d/fuego.conf + apt-get install
> 2) in addition to the test scenarios variables that are pre-defined,
> allow user to redefined/override those when executing the test using
> the command line. For example fuego-release-test (fuego-rt) would
> default to test official repository with the branch "next", but one
> could override to test a private repo with a custom branch.
> This would solve the need to "patch" the correct value at entrypoint.sh:
>    sed -i "s/FUEGOTEST_REPO/${test_repo_escaped}/"
> /fuego-core/engine/tests/Functional.fuegotest/spec.json
>    ...
>    ftc add-jobs -b fuego-test -t Functional.fuegotest
> With something like:
>    ftc add-jobs -b fuego-test -t Functional.fuegotest -v
> FUEGOTEST_REPO=${test_repo_escaped}
We've talked about adding the ability to define a test
variable on the command line, when adding jobs
or running tests, that would override the value contained
in a spec file.

This is highly desirable.

I'm still, however, wrapping my head around the fuego release
self-test case, which I don't understand yet.  Talking
about this feature in that context may be too much for my
little brain to handle, at the moment.
 -- Tim

More information about the Fuego mailing list