Skip to main content

Configuration File Reference

Instead of passing all options on the command line, you can use a configuration file. When the greenframe analyze command is run, GreenFrame will look for a .greenframe.yml file in the current directory. If it exists, it will be used instead of the command line options.

Example configuration file​

.greenframe.yml
baseURL: YOUR_APP_BASE_URL
scenarios:
    - path: PATH_TO_YOUR_SCENARIO_FILE
      name: My first scenario
      threshold: 0.1
projectName: YOUR_PROJECT_NAME
samples: 3
useAdblock: true
containers:
    - 'CONTAINER_NAME'
    - 'ANOTHER_CONTAINER_NAME'
databaseContainers:
    - 'DATABASE_CONTAINER_NAME',
envFile: PATH_TO_YOUR_ENVIRONMENT_VAR_FILE
envVar:
    - envVarA: 'An environment variable needed for the scenario (ie : a secret-key)',
    - envVarB: 'Another environment variable needed'

Options​

baseURL: Your app base URL (e.g http://localhost:3000), note that page.goto in your scenario method will be affected by this base url.

scenarios: Enter a list of scenarios that you want to run.

  • path: Absolute path regarding to the configuration file to locate your scenario.
  • name: Add a name to your scenario to identify it inside the GreenFrame app.
  • threshold: in g eq. co2, the scenario will fail if the consumption passes this limit.

projectName: A name of your project, if the project doesn't exist, it will be created. It's used to manage the history of your project. If you omit it, GreenFrame CLI will search a PROJECT_NAME env variable or will take the name of your project.

samples: (default: 3) Number between 2 and 10 of runs of your scenarios. A high number will improve the duration of your CI but will also increase the precision.

useAdblock: (default: false) useAdblock allows you to block third-party scripts like ads or trackers. Use this mode if you want to analyze an app that contains third-party scripts and if you encounter difficulties or simply just want to ignore their costs.

containers: A list of your server containers name (like API, proxy, or cache system) that you want to measure during an analysis. Enter the same name as you see it when typing docker ps, you can also fix it inside the docker-compose by using the container_name field

databaseContainers: A list of your database containers name (like PostgreSQL or mongoDB) that you want to measure during an analysis. Enter the same name as you see it when typing docker ps, you can also fix it inside the docker-compose by using the container_name field

dockerdHost: (default: unix:///var/run/docker.sock) The docker daemon host.

dockerdPort: (default: 2375) The docker daemon port.

threshold: In g eq. co2. The analysis will fail if the sum of all scenarios consumption passes this limit.

envFile: Path to an env file containing environment variables needed to run your scenarios (Can be used in addition to envVar). In this env file, you can have either couples of variables/values or only variables. When no value is specified, the runner assume that the environment variable exists in the execution context.

.envFile
ENV_VAR_LOGIN=myLogin
ENV_VAR_PASSWORD

envVar: List of environment variables needed to run your scenarios (Can be used in addition to envFile). You can enter a mix of couple of variables/values or only variables. When no value is specified, the runner assume that the environment variable exists in the execution context.

.greenframe.yml
baseURL: YOUR_APP_BASE_URL
envVar:
    - ENV_VAR_LOGIN=myLogin,
    - ENV_VAR_PASSWORD,

Kubernetes Options​

GreenFrame can perform an analysis on a Kubernetes cluster. To do so, you need to add some specific configuration to your .greenframe.yml file.

//...
kubeContainers:
  - "demo:name=app"
kubeDatabaseContainers:
  - "demo:name=db"
kubeConfig: "/path/to/kube/config"

kubeContainers: A list of your server containers' names. It takes the form of namespace:label[/container_name]. The container name is optional. If none is provided, we analyze the pod level (and this is the recommended way to use GreenFrame). If you need to analyze a container inside a pod, specify the container name (for example "demo:name=app/api").

info

You can find the name of the containers by running kubctl get pods -n NAMESPACE -o json and looking for the spec.containers.name field.

kubeDatabaseContainers: A list of the database containers' names. It takes the form of namespace:label[/container_name]. The container name is optional. If none is provided, we analyze the pod level (and this is the recommended way to use GreenFrame). If you need to analyze a container inside a pod, specify the container name (for example "demo:name=db/postgres").

kubeConfig: The path to your Kube config file. If a default config exists in your environment (usually ~/.kube/config) this configuration becomes optional.

The other fields are the same as the ones described above.

Using Another Configuration File​

You can specify another location for your .greenframe.yml file by using the -C command:

greenframe analyze -C ./another_folder/.greenframe.ci.yml

Running a GreenFrame Analysis with Custom Hosts​

Sometimes your app should run on a specific local URL that is not localhost. In this case, you probably have written a mapping between 127.0.0.1 and your specific URL in your /etc/hosts.

GreenFrame CLI cannot access this mapping. You should update the GreenFrame configuration file to let the CLI access these URLs.

.greenframe.yml
extraHosts:
    - 'extra-host.com'
    - 'another.extra-host.com'

Go to the root folder of the app you want to analyze, and paste the following scenario:

./scenario.js
const scenario = async (page) => {
    // Go to the url passed to the command line (see below)
    await page.goto('', { waitUntil: 'networkidle' });
    await page.waitForTimeout(3000); // Wait for 3 seconds
    await page.scrollToElement('footer'); // Scroll to the bottom of the page (change the element name depending on your markup)
    await page.waitForNetworkIdle(); // Wait for every request to be answered - as a normal user would do

module.exports = scenario;