Hello friends, I know testing this release has not been a walk in the park but nevertheless, I want to say thank you for the spirit and patience. Since the tests were flopping on the github action, we opted to run automated tests locally in the feature file linked to every workflow and spinned the tests against the https://uat-refapp.openmrs.org/openmrs/ which is running Reference Application 2.13.0-SNAPSHOT and this is our findings. As communicated prior we anticipate the release to come-out anytime from now not unless we face any constrain beyond our control.
Thanks!
It’s a bit strange to see only 25% of the automated tests passing in github actions when running with the uat server for RefApp 2.13.0-SNAPSHOT. The rest of the tests are throwing a general server failure(HTTP 404 not found), I am not able to figure out the real cause of the issue but this could be something worth considering before releasing the refapp.
The manual attempt could not reproduce any of those errors. Taking further investigation on github actions have been able to figure out the reason why the tests were failing before and made commits (a8cd9eb, a6665d8) that made the tests pass. Though there remains only two tests failing which am investigating but I realize enabling the includes.csrftoken functionality makes all the tests fail login step probably because the functionality was introduced in platform 2.6.0 and the uat is using 2.5.9.
Unable to locate element: *[name='OWASP-CSRFTOKEN']
I may not tell why we are not using the recent released platform version, @jwnasambu could you help me understand the pitfall that were occurring when using the new version which led to this downgrade?
@dkayiwa we now have all the tests passing in github actions running against uat server when includes.csrftoken is disabled otherwise they all fail with the error I shared above. Is it worth looking for the workaround to have the tests pass when the property is enabled or @jwnasambu can proceed with releasing the refapp 2.13.0?
This makes sense! @jwnasambu you should be good to go →
@dkayiwa, something confusing is that we are running the tests in github actions against a local host instance configured in a dockerized environment. The local host uses an updated qa image, the platform version is 2.5.9, includes.csrftoken is enabled and all the tests are happily running. Could you help me understand what is happening here?
@kdaud kindly am looking at the logs on the github action under Run qaframework on selenium and am getting this
{"error":"Could not process your messages because of the following error(s): \n- project-access-token: can't be blank"} Does this error matter or not? It’s the massage appearing on every workflow.
Those logs are pointing out the expiry of project-access-token: ${{secrets.CUCUMBER_IO_TOKEN}} and requires updating the token. All the workflows are configured to process a build plan message at the end of the test run, the message is published on cucumber reports and this setting resides in every workflow, you may take a look at one → here
Thanks for the clear explanation @kdaud . All the tests are passing both locally and on github action. Should I wait for the ticket to be merged for me to proceed with the next release step?
I don’t think since we were testing out our new baby refapp with the automated tests and has proven worth after the tests running through her major functionalities/user workflows.
My recommendation would be for you moving to the next release step however, @dkayiwa’s advise at this step should be considered before you move on to the next stage.