Troubleshooting
Integration errors
Connection problems
Test connection does not pass successfully
Why it could happen
- Credentials you provided aren't correct.
- No connection to the integrated system.
- API was updated on the integration side.
How to fix
Credentials you provided aren't correct
- Check you have copied/entered correct password or token required by the integration.
- tokens and passwords must have no spaces in the beginning and at the end, these are considered as characters and adding spaces will make your password or token incorrect for sake of authentication.
- Check username string is what is expected by the integration.
- Check you are using correct string for the username.
- Carefully read the integration description, it states what exactly need to be used as a username; that could be username or email and in 100% of cases these aren't interchangeable.
No connection to the integrated system
This requires involving of support and your DevOps or engineers responsible for infrastructure.
This could result in the message Can't establish connection in the UI.
To troubleshoot the issue you need to do the following
- Collect the logs from report service
- Check the logs for errors like
java.net.UnknownHostException
If no such messages available in the logs, try to enable more detailed logging for integrations as described below.
Enable debug logging for the integrations.
- add a new environment variable
LOGGING_LEVEL_IO_QAMETA_ALLURE_TESTOPS_INTEGRATION
with valuedebug
. - restart the deployment (service must get the new parameters)
- try the operation which failed
- collect the logs from report service
- check the logs for errors
400 bad request
HTTP FAILED
java.net.UnknownHostException
- The errors above usually have more detailed description above and below error line
UnknownHostException
generally means Allure Testops has no connection to the system you described in the integration settings.
- add a new environment variable
If UnknownHostException
occurs, then you either need to check you provided correct URL for the integration, or you need assistance from your network team to troubleshoot the issue.
If you are struggling with the comprehending of the log files, create Support request at our help portal using your corporate email address during the registration.
API was updated on the integration side
This can be fixed only by involving of your DevOps or engineers responsible for your infrastructure and Allure Testops tech support, and then it might require additional development; and could take considerable time.
- Perform all the actions described above in No connection to the integrated system.
- debug logging for the integrations need to be enabled.
- If the logs do not contain symptoms of troubles with the connections, create Support request at our help portal using your corporate email address during the registration.
GitHub (CI) integration
GitHub returns a 422 Unprocessable Entity error when trying to trigger a workflow
Usually, this means that one or more required workflow parameters (the ones starting with ALLURE_) are missing in the GitHub workflow YAML file. You can check the list of required parameters here.
Test results
Test results are marked as orphaned
Reason
The test results in Allure Testops launch will be marked as Orphaned in following cases.
An invalid AS_ID (ALLURE_ID)is received in the results
- ALLURE ID does not yet exist in the instance of Allure Testops, this attribute is managed by Allure Testops and you cannot use random IDs.
- There is no valid ALLURE_ID, and there is no full path (test case selector) in the test results. Full path (selector) is used to unmistakably match a test result to a test case. If you are using some 3rd party integration, it could disregard this parameter, and it will work with Allure Report, but it's crucial for working with Allure Testops.
Possible solution
No full path data
To be able to import the results containing no data on full path, the valid AS_ID (ALLURE_ID) attributes should be provided via code and be available in the test results.
You also need to check if you are using most recent dependencies in your project and then check the generation of the results again.
For the dependencies please check the official repos of Allure Report project at GitHub: https://github.com/allure-framework
Incorrect ALLURE_ID (AS_ID) and no full path data
You can only assign an existing Allure ID to a via the code, if your test framework/PL aren't supported via JetBrains IDEs, you need to create a manual test case, copy its ID, and provide its ID to the code, then upon arrival the manual test case will be replaced by the data from the automated test result.
Test results are not shown or shown multiple times
See Test results FAQ.
Automated tests are stuck on "In progress" status when run or rerun
This can happen if the received test result parameters or environment variables differ from the expected values.
For example, if you have set two environment variables when triggering a test run, say OS=iOS and VER=123, but then the value of one of them got changed during the run (say, it's being assigned dynamically and always gets new value), Allure Testops will create a new test result upon receiving the result file, and will still wait for a result with the correct values (which would never arrive).
The same will happen if Allure Testops receives a test result with a different parameter value.
If you are using test parameters or environment variables to store dynamic values, consider using attachments for this purpose instead. Alternatively, some integration modules allow you to mark parameters as excluded so changing their values would not lead to creating a new test result instead of one we expect to receive.
Services do not start
Report service or UAA service does not start (database lock)
If you find one of the following messages in the log
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'liquibase' defined in class path resource org.
springframework.beans.factory.BeanCreationException: **Error creating bean with name 'liquibase'** defined in class path resource [org/springframework/boot/autoconfigure/liquibase/LiquibaseAutoConfiguration$LiquibaseConfiguration.class]:
Invocation of init method failed;
nested exception is liquibase.exception.LockException:
Could not acquire change log lock.
liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...
liquibase.lockservice: Waiting for changelog lock...
it means that the database is locked and the service cannot access it. It can happen if the service was abruptly shutdown due to infrastructure or network failure.
To fix this:
Stop all Allure Testops services. Keep the PostgreSQL server running.
Docker example:
docker compose stop allure-gateway allure-uaa allure-report
Log in to the report database using psql:
psql -h <host> -U <user> <database>
.Docker example:
docker exec -it <containder id> psql -h 127.0.0.1 -U report report
Make the following query to display all database locks.
SELECT * FROM databasechangeloglock;
Find and remove the lock that is preventing the services from starting.
UPDATE databasechangeloglock SET locked=FALSE, lockgranted=NULL, lockedby=NULL WHERE id=1;
Start the previously stopped Allure Testops services.
Docker example:
docker compose start allure-gateway allure-uaa allure-report
UAA service crashes or uses too much CPU when making a large number of API calls
If you are using an API token that you have generated in your profile to access the API, you need to switch to OAuth authentication (using JWT as Bearer token). See API Authentication for more information.
UI errors with code 409
"Request failed with status code 409" when trying to move a test case to another project
This can happen when an automated test case with the same properties already exists in the target project.
For an example, imagine the following situation:
- You upload two test results to Project A resulting in two new test cases being created. Let's say they have IDs of 1 and 2.
- You move one of the created test cases (ID = 2) to Project B.
- You upload results for the same two test cases to Project A. One of the test cases already exists in Project A (ID = 1), so one new test case will be created (ID = 3).
Now, if you try to move test case with ID number 2 from Project B back to Project A, an error will occur because an identical test case (except for the ID) already exists in Project A.
Getting binary files for the deployment
Cannot download packages from qameta.jfrog.io
We have moved all our packages to dl.qameta.io.
You can find the updated installation instructions here. Your old access credentials should work, but if they don't, contact our support.
Cannot log in to Docker Desktop using Qameta credentials
This is the correct behavior. The credentials you received from the Qameta sales team should only be used with the Docker command-line tool to download the Allure Testops images as described in this article.
User login issues
Cannot log in to Allure Testops as Admin
Make sure that you are trying to log in using the built-in administrator account and not a third-party authentication account.
- If you are using an external IAM system to authenticate users (LDAP, SAML2, OpenID) as main option for the authentication, then the login to the system with local account needs to be done using https://{URL}/login/system address.
If you are using Allure Testops Server, you can find the password in the configuration files of your instance.
If you are using Allure Testops Cloud, you can find the password in the message you received upon creating your instance. The password resets every time an instance is updated or rebooted.
Error 401: CSRF Token Missing
If you see an error in browser's DevTools which looks like "Request failed with status code 401. The expected CSRF token could not be found" when an end user cannot login to Allure Testops, try to do the following.
The problem is most likely linked to a "stuck session" in Redis which is used for storing user sessions. Root cause of such "stuck session" can be different time zones user operates in, i.e. Allure Testops is in TZ1, the user's computer is in TZ2, and user utilizes VPN connection which endpoint is in TZ3. This soup of timezones can cause the creation of a session which is always expired form its very start or not yet active in point of view of Allure Testops instance.
- Try the
redis-cli FLUSHALL
: command.
redis-cli FLUSHALL
Use this command to clear the session data stored in Redis. Remember that this action will reset sessions for all users and they will be logged out from the UI.
or alternatively you can
- Restart Redis service to get the same result as
FLUSHALL
command.
Redis' data for the usage with Allure Testops mustn't be persistent, so restart will delete all the data on current users' sessions.
Important: Both actions will cause user sessions to be reset. Consider informing users in advance or performing them after business hours.