KYUA.CONF(5)

πŸŽ€ NAME πŸŽ€

Okay bestie, this is kyua.conf β€” the configuration file for the kyua tool, aka the KYUA.CONF(5) manual page. It’s giving β€œtiny file, big main-character energy” πŸ’…βœ¨

✨ SYNOPSIS ✨

Here’s the synopsis, no cap:

syntax(int version);

Variables: architecture, execenvs, platform, test_suites,
unprivileged_user.

πŸ’– DESCRIPTION πŸ’–

The configuration of Kyua is literally a simple collection of key/value pairs called configuration variables. Some configuration variables have a special meaning to the runtime engine implemented by kyua(1), and some variables only have meaning in the context of particular test suites.

Configuration files are Lua scripts. In their most basic form, their whole purpose is to assign values to variables, but you have the freedom to implement any logic you desire to compute such values. Icon behavior, honestly.

🧚 File versioning

Every kyua.conf file starts with a call to syntax(int version). This call determines the specific schema used by the file so that future backwards-incompatible modifications to the file can be introduced.

Ngl, that syntax() call is the vibe check for the whole file β€” it locks in the schema, bestie.

Any new kyua.conf file should set version to 2.

πŸ”₯ Runtime configuration variables

The following variables are internally recognized by kyua(1):

  • architecture β€” name of the system architecture (aka processor type). 🧠
  • execenvs β€” whitespace-separated list of execution environment names. Only tests which require one of the given execution environments will be run. See kyuafile(5) for the list of possible execution environments. πŸƒβ€β™€οΈ
  • parallelism β€” maximum number of test cases to execute concurrently. Multitasking queen behavior. πŸ‘‘
  • platform β€” name of the system platform (aka machine type). πŸ’»
  • unprivileged_user β€” name or UID of the unprivileged user. If set, the given user must exist in the system, and their privileges will be used to run test cases that need regular privileges when kyua(1) is executed as root. πŸ”

🌸 Test-suite configuration variables

Each test suite is able to recognize arbitrary configuration variables, and their type and meaning is specific to the test suite. Because the existence and naming of these variables depends on every test suite, this manual page cannot detail them; please refer to the documentation of the test suite you are working with for more details on this topic.

Test-suite specific configuration variables are defined inside the test_suites dictionary. The general syntax is:

test_suites.<test_suite_name>.<variable_name> = <value>

where test_suite_name is the name of the test suite, variable_name is the name of the variable to set, and value is a value. The value can be a string, an integer or a boolean. πŸŽ€

πŸ“ FILES

  • /usr/share/kyua/examples/kyua.conf β€” sample configuration file. Use it, bestie. 🫢

πŸ“ EXAMPLES

The following kyua.conf shows a simple configuration file that overrides a bunch of the built-in kyua(1) configuration variables:

syntax(2)

architecture = 'x86_64'
platform = 'amd64'

The following is a more complex example that introduces the definition of per-test suite configuration variables:

syntax(2)

-- Assign built-in variables.
unprivileged_user = '_tests'

-- Assign test-suite variables.  All of these must be strings.
test_suites.NetBSD.file_systems = 'ffs ext2fs'
test_suites.X11.graphics_driver = 'vesa'

🫢 SEE ALSO

  • kyua(1) β€” the main event. Go read it, iykyk. πŸ’œ

Signed off with love by Debian on March 22, 2024 β€” this iconic manual page is KYUA.CONF(5), and yes, she ate πŸ’–βœ¨

πŸ“¦ where this page comes from