Here is a short table that relates a few Jenkins terms to Fuego terms:
|Jenkins term ^||Fuego term ^||Description ^|
|this is a long-running jenkins process, that executes jobs. It is usually (?) assigned to a particular node|
|node||board||item being tested (Fuego defines a Jenkins node for each board in the system)|
|job||test||a collection of information needed to perform a single test|
|request||a request to run a particular test on a board|
|build||run (or 'test run')||the results from executing the job or test|
|plan||the plan has the list of tests and how to run them (which variation, or 'spec' to use)|
|spec||the spec indicates a particular variation of a test|
- base test script
- this is a small script associated with a particular test. It provides a set of test functions that are executed on the host (in the container) when a test is run.
- a type of test where one or more numeric metrics indicates the status of the test. See Benchmark parser notes for more information about processing these metrics.
- binary package
- a tarfile containing the materials that would normally be deployed to the board for execution.
- board file
- a file that describes (using environment variables) the attributes of a target board. This has the extension .board and is kept in the directory /fuego-ro/boards.
- console log
- the full output of execution of a test from Jenkins. See Log files for details.
- the developer log for a test. See Log files for details.
- the name of a target board in the Fuego system.
- device under test
- in test terminology, this refers to the item being tested. In Fuego, this may also be called the Device, target, or node.
- This refers to a set of software that is running on a Linux machine. Example "distributions" are Debian, Angstrom or Android. The distribution defines file locations, libraries, utilities and several important facilities and services of the machine (such as the init process, and the logger).
- functional test
- a type of test that returns a single pass/fail result, indicating whether the device under test. It may include lots of sub-tests.
- an advanced continuous integration system, used as the default front-end for the Fuego test framework. see Jenkins
- log file
- Several log files are created during execution of a test. For details about all the different log files, see Log files
- In Jenkins terminology, a job is a test
- a numeric value measured by a benchmark test as the result of the test. This is compared against a threshold value to determine if the test passed or failed. See Benchmark parser notes
- program to collect "overlay" data from various scripts and data files, and produce the final test script to run. see Overlay Generation
- parsed log
- the test log file after it has been filtered by log_compare. See Log files for details.
- a python program, included with each Benchmark test, to scan the test log for benchmark metrics, check each against a reference threshold, and produce a plot.png file for the test. See parser.py and Benchmark parser notes for more information.
- To provision a board is to install the system software on it. Some board control systems re-provision a board for every test. In general, Fuego runs a series of tests with a single system software installation.
- reference log
- this file (called "reference.log") defines the regression threshhold (and operation) for each metric of a benchmark test. See reference.log and Benchmark parser notes
- spec variable
- a test variable that comes from a spec file. See Test_variables#Spec_variables
- stored variable
- a test variable that is stored in a read/write file, and can be updated manually or programmatically. See Test_variables#Stored_variables
- the system log for a test. This is the system log collected during execution of a test. See Log files for details.
- This is a collection of scripts, jenkins configuration, source code, and data files used to validate some aspect of the device under test. See Fuego Object Details for more information.
- test log
- This is the log output from the actual test program on the target. There are multiple logs created during the execution of a test, and some might casually also be called "test logs". However, in this documentation, the term "test log" should be used only to refer to the test program output. See Log files for details.
- test package
- This is a packaged version of a test, including all the materials needed to execute the test on another host. See Test package system
- test phases
- Different phases of test execution defined by Fuego: pre_test, build, deploy, test_run, get_testlog, test_processing, post_test. For a description of phases see: Architecture#fuego_test_phases
- test program
- a program that runs on the target to execute a test and output the results. This can be a compiled program or a shell script (in which case the build step is empty)
- test run
- this is a single instance of a test execution, containing logs and other information about the run. This is referred to in Jenkins as a 'build'.
- test script
- the shell script that interfaces between the fuego core system and a test program. The script declares a tarfile, and functions to build, deploy and run the test. The test script runs on the host. This is also called the 'base test script'. For details about the environment that a script runs in or the functions it may call, see Variables, Core interfaces, and Test Script APIs
- test variable
- This is the name of a variable available to the a test during it's execution. See Test variables
- test variable script
- this is a script generated at test execution time by the overlay generator. It is generated when the test script (base test script) is executed, and environment variables are used to source various files and inputs for the final script. It is called 'prolog.sh'
- defines the toolchain or SDK for the device. This is used to select a set of environment variables to define and configure the toolchain for building programs for the intended test target.
- file containing the definition of toolchain variables for the different platforms installed in the container (and supported by the test environment) See tools.sh for details.