Gathering the information about test environment
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.
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.
In your gitlab project locate Settings => CI/CD and locate Variables section.
Expand the Variables section and add variable name (Key) and its default value.
Include this variable in your tests
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.
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!
… and run the build job again from Gitlab’s UI.
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.
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.
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.