Skip to main content

Creating Variables from Config Files

Cycle 2.8 adds the following new Steps for assigning variables from a config file:

I assign values from config file "<path to .conf file>" to variables I assign value of "<entry in conf file>" from config file "<path to .conf file>" to variable "<new variable name>"

The formatting of a .config file that these Steps can interpret can be as simple as key/value pairs:

    devcod = RDT001
    vehtyp = FORK
    user = admin
    pass = 1234
    wh_id = WMD1

Comments can also be included in their own lines or at the end of a line using // or #:

    // device code
    devcod = RDT001
    vehtyp = FORK // vehicle type
    user = admin
    pass = 1234 # change this
    # warehouse ID
    wh_id = WMD1

Utility Feature Use Case​

In addition to this, config files can reference other config files. For example, when storing all config files in a directory named “config” which includes a default.conf looks like:

    devcod = RDT001
    vehtyp = FORK
    user = admin
    pass = 1234
    wh_id = WMD1

And two additional files WMD2.conf and WMD3.conf in that directory that include the default.conf:

WMD2.conf​

    include "default"
    wh_id = WMD2

WMD3.conf​

    include "default"
    wh_id = WMD3

In this case, running I assign values from config file "config/WMD2.conf to variables would result in a variable “devcod” with a value of “RDT001" which comes from default.conf, but also the new value of “WMD2” for “wh_id”.

New values can also be defined when including another config file. Therefore, if the directory also conatins a file WMD2-ClientA.conf like this:

    include "WMD2"
    client_id = CLIENT_A
    devcod = RDT001W

The additional variable of client_id would be assigned when running I assign values from config file "config/WMD2-ClientA.conf" to variables, WMD2.conf would pass in the wh_id of WMD2, devcod of RDT001W, and vehtyp of FORK since WMD2.conf is included, which includes default.conf.

This can simplify a Utility Feature that is loading environment-specific information for a test. It eliminates all the extra Steps that were previously running a loop to read lines from a CSV and create variables from various CSVs.

CI/CD Use Case​

Environment variables can also be referenced in config files. Use the following for a more dynamic approach for a device code:

    devcod = RDT001
    devcod = $\{?DEVCOD}
    vehtyp = FORK
    user = admin
    pass = 1234
    wh_id = WMD1

In this case, running I assign values from config file "config/default.conf" to variables with no DEVCOD environment variable set prior to running cycle, RDT001 would be used as the value. However, if a DEVCOD environment variable is set, that value would be used.

Therefore, by using ths following jenkins file:

    pipeline {
    agent none
    environment {
        DEVCOD = "LXE007"
    }
    stages {
        stage('first') {
                agent { label 'master' }
                steps {
                sh "cyclecli -p project1 login.feature"
                }
            }
        }
    }

The feature importing default.conf with the ${?DEVCOD} syntax in it would dynamically get LXE007 as the value when the feature ran.

This can be useful in sticking a password into a jenkins secret and making that available as an environment variable in the pipeline.

(In such a case, it is advisable to include a default value like RDT001 above, for the sake of running the feature from the GUI.)

** Note that if there is a hard-coded value for devcod in a config file which included default.conf, that would override the default.conf value totally, including the environment variable.

Another dynamic use of this is, in the case where there is a default.conf, WMD2.conf, and WMD3.conf, we can create an env.conf in that directory with the following:

    conf_file = config/default.conf
    conf_file = $\{?TEST_ENVIRONMENT}

Then a feature can use:

    I assign value of "conf_file" from config file "config/env.conf" to variable "conf_path"
    I assign values from config file $conf_path to variables

Now if running locally with no environment variables set, Cycle would load the default.conf. But in a jenkins pipeline, by setting TEST_ENVIRONMENT to config/WMD2.conf or config/WMD3.conf those values will be used dynamically at run time without having to change any files in the project at all.