Skip to content

Latest commit

 

History

History
125 lines (99 loc) · 5.5 KB

File metadata and controls

125 lines (99 loc) · 5.5 KB

<< back

Config file

By default, Teuton projects use config.yaml as configuration file.

Our tests may or may not have a configuration file. It is common to have a configuration file to easily adapt the test execution to different hosts, environments or situations. For example: adapt the config file for each course for the different students we are going to evaluate.

Creating new project

  • Create a new project teuton new foo.
Creating foo project
* Create dir        => foo
* Create file       => foo/config.yaml
* Create file       => foo/start.rb
  • We now have the following files.
foo
├── config.yaml
└── start.rb
  • Configuration file content.
# File: foo/config.yaml
---
global:
cases:
- tt_members: TOCHANGE

The configuration file is in YAML format with two main sections: global y cases. The global section can be empty. Parameters defined in the global section will be accessible to all cases. The cases section contains specific parameters for each case.

Global section vs cases section

Example:

# File: examples/03-remote_hosts/config.yaml
---
global:
  host1_username: root
cases:
- tt_members: student_1
  host1_ip: 192.168.1.201
  host1_password: secret_1
- tt_members: student_2
  host1_ip: 192.168.1.202
  host1_password: secret_2
- tt_members: student_3
  host1_ip: 127.0.0.1
  host1_password: secret_3
  • The parameter host1_username is defined in the global section, so all cases will read the same value. Example: get(:host1_username) == "root".
  • The parameters tt_members, host1_ip, and host1_password are defined in each case. So, every student has diferents values. The student number 1 will have one value, student number 2 another, and so on.

It is posible to add as many parameters as you need. But remember that parameters defined in the global section will be available to all students (cases), while parameters defined in the cases section will be specifically defined for each student (case).

Reserved params

It is posible to add all the parameters you need into your configuration file, but some parameter names has special meaning. Reserved parameter names begin with prefix tt_.

Param name Section Status Descripction
tt_members cases Required Student name if it is an individual assignment or names of the members if it is a group assignment
tt_moodle_id cases Optional Student identifier on the Moodle platform. Example: student's Moodle email address
tt_moodle_max_score global Optional Default value: 100. The grades generated by Teuton have values ​​between 0 and 100. But by changing this parameter to 10, for exmaple, the values are adjusted to between 0 and 10 before saving the grades into the moodle.csv file
tt_include global Optional The contents of the files within the directory defined by the parameter are added to our main configuration file
tt_sequence global Optional By default, all cases are evaluated in parallel unless sequential mode is enabled. Sequential mode is useful for debugging processes.
tt_source_ip cases Auto Automatically filled in during remote setup. This value is completed when the student sends their configuration remotely.
tt_source_file cases Auto Automatically filled in during the configuration loading. This value is populated when the configuration files from the folder defined by the tt_include parameter are read.
tt_skip Optional False by default. To skip a case and not evaluate it, set the value to true.
tt_testname global Optional Customize your test name

Host properties

Parameters used to define the properties of each host must begin with an identifier (HOSTID).

Lits of available host properties:

Param name Required Default value Description
HOSTID_ip Yes IP address or hostname of the host identified by HOSTID
HOSTID_username No User account to access HOSTID
HOSTID_password No Password to access HOSTID
HOSTID_protocol No ssh Available options: ssh (default), telnet
HOSTID_port No 22/23 Default value: 22 (ssh), 23 (telnet)
HOSTID_route No This option is used to configure a gateway to access HOSTID

We can create as many host configurations as different devices are required to complete the activity.

If HOSTID_password is not defined, then SSH connection will use the SSH keys.

Example: If each student needs two hosts for the activity, one web server and the other as web cliente, we need to define 2 hosts: one with HOSTID serverand the other wiht HOSTID client:

global:
cases:
- tt_members: student_1
  server_ip: 192.168.13.1
  server_username: root
  server_password: server_secret_1
  client_ip: 192.168.13.2
  client_username: david
  client_password: david_secret_1

Or we can use other names, for example one with HOSTID host1 and the other with HOSTID host2.

global:
cases:
- tt_members: student_1
  host1_ip: 192.168.13.1
  host1_username: root
  host1_password: server_secret_1
  host2_ip: 192.168.13.2
  host2_username: david 
  host2_password: david_secret_1