Gathering environment information

Gathering the information about test environment

For what?

It is quite rare situation when tests run without any parameters which define different conditions to run the tests. These conditions could be for instance:

  • different browsers to run the tests on for web UI tests.
  • different hosts to run the tests on, e.g. qa server, staging server.
  • VCS branch - to test changes before they appear in master branch. It’s a bit tricky for gitlab.

When Allure TestOps gathered this information, it will allow you starting the build jobs with the environment of your choice right from its UI.

How?

Let’s find out…

Add environment parameters to a Job on Gitlab side

Now, say by default our test will check the production site using its API but from time to time we might want to test QA version of the site or staging or whatever version we could have. This requires tests’ parameterisation.

Adding parameters

  1. In your gitlab project locate Settings => CI/CD and locate Variables section.

  2. Expand the Variables section and add variable name (Key) and its default value.

    Add env variable

  3. Include this variable in your tests

    Env variable HOST

The next steps is the configuration of Allure TestOps - you must explicitly mark the variables which Allure TestOps needs to process.

Set up Allure TestOps to receive environment variable from Gitlab

Administration section of Allure TestOps

Let’s set up Allure TestOps project settings for this environments information processing.

If you haven’t registered the environment variable yet, then first you need to go to the Administration section of Allure TestOps (you need admin’s rights) and introduce a new variable, it will be used to link environment variables from different CI systems to internal environment variable of Allure TestOps.

By doing this you will be able to link similar environment variables from different CIs to global environment variable, so Allure TestOps will then automatically match incoming data with known variables.

Introduce new environment variable

Project’s Environment section

Jump to your project Settings => Environment => Create => Add the environment variable to Key section => Select registered Environment variable from the drop-down list. That’s it!

Add env variable to a project

… and run the build job again from Gitlab’s UI.

Env variable is populated to Allure

Running on alternative branch

Getting the information about the branch used for tests execution is quite easy. If you check the output of printenv in your build job, you will see that there is a couple variables you can use to get the information about the used branch:

printenv
...
CI_COMMIT_BRANCH=nonMaster
...
CI_COMMIT_REF_NAME=nonMaster
...

It’s important to know, these are read only and you can’t use them to set the branch for the test execution.

So, to see what was the branch used for job run, you can link CI_COMMIT_REF_NAME with global Branch variable in the project settings.

ALT TEXT

But if you want to specify the branch to be used when starting a build job from Allure TestOps, you need to use global Branch variable linked to the same project variable Branch. You don’t need to set up this variable, it’s done by Allure TestOps internally for Gitlab.

ALT TEXT

This project’s Branch variable is used by Allure TestOps to set the branch for tests run on Gitlab side, so changing it will allow you starting alternative branch for the tests execution.

Now, it’s time to run your build jobs from Allure TestOps server.