Good News is that i’m in final stages of successful deployment. I am stuck, where I cannot see the consolidated report.html in the artifacts. Have been using mochawesome for reporting and was successful with single report as seen in the screenshot below
But the merging various test html’s after following the guide from the link Using Mochawesome Reporter with Cypress - DEV Community 👩💻👨💻 the octopus deploy is not happy with the result and cant view the .html file which otherwise works OK from visual studio code. Creates consolidated result report in the path configured locally on VSCode
Question is do I need to install and configure mochaesome reporter on my worker(ubuntu machine) for it to work? I did try but throws warnings/errors as below.
From that error message, it looks like you might not be using a supported version of NodeJS for this particular module.
I’d recommend using a supported version of NodeJS to see if this takes care of things (>= 14.0.0), but let me know how it goes in investigating this avenue further.
I hope this helps, but let me know if you are still having trouble and I’d be glad to help further.
Thank you for pointing that out. It was indeed my next task. After many issues I have now upgraded to NodeJS 18x. Also installed required mochawesome software yet the consolidated .json and consolidated.html doesn’t get displayed hence deployment fails. However individual .json are displayed in the summary when searched via run a script using bash script.
I am after the end report.html(consolidated report of all test results). Need your advise on how to get the end report from octopus deploy. Am i missing anything that needs to be included within my dockerfile? As my cypress tests run in container on ubuntu worker.
Thanks for getting in touch! I’ll jump in for Britton for the time being as he’s currently offline as part of our US-based team.
While I’m not sure exactly what could be missing here at this stage, I think it’d be worth pointing you to a blog post a colleague wrote a little while back that may be very helpful to have a read through.
Thanks for jumping in, Yes I did follow the same link you sent as I original guide and everything is in place. But this guide doesn’t have anything related to merging reports, so installed all the necessary s/w for merging which is all good on Visual Studio code with consolidated report.
Rechecked my configs and the docker run also creates merged html, and this image is then being pushed onto AWS ECR and called within Octopus Deploy. My latest deployments on octopus deploy though runs cypress tests, fail only because they cant find the generated report path.
Consolidated default report path is mydir/cypress/reports/html/index.html. And it always checks in mydir even though I have provided full path /etc/octopus/Cypress-worker/Work/*/mydir/cypress/reports/html/index.html within my bash script in Run a script step.
Thanks for following up with that additional information. Unfortunately I couldn’t say at this stage. I think the best way forward to try to understand what might be causing this unexpected behavior would be to get a copy of your verbose task log from a deployment that is exhibiting this issue (guide on enabling this can be found in this documentation page). Would you be willing to generate that and upload it to this secure link for us to review?
I’m hoping that helps us identify what’s going on!
At the moment, I have changed the approach and the deployments fail because of permissions issue. The attached file of permission denied is on nodemodules directory. I have run the docker container from linux server and worker is on Ubuntu. How to sort the permission issue.
I’m stepping back in for Kenny, as he is offline at the moment, but I’m happy to continue helping!
Thank you for uploading that task log for our review.
In taking a look, I see the following line:
13:49:33 Error | /etc/octopus/Cypress-worker/Work/xx/Script.sh: line 8: /e2e/node_modules/inline-assets/bin/inline-assets.js: Permission denied
From this, it seems like there might be a permissions issue on the node_modules directory, which you may need to account for in your process (i.e. via chmod or chown command(s)).
Typically the node_modules directory is populated dynamically when you install the requirements for the project (i.e. by using npm i), so if you are including these files as part of the deployment you may want to look into excluding these and then letting this get built out dynamically via the npm install command.
Another thing you could do is leverage the special variable Octopus.Calamari.CopyWorkingDirectoryIncludingKeyTo to copy the Calamari working directory to another location, which would let you manually run through things as Octopus sees the process (as long as you are using the same user that Octopus Deploy is using).
With your process running in a container the Octopus.Calamari.CopyWorkingDirectoryIncludingKeyTo might not be easy to use, so another thing you could do is add a long sleep step to your process, which would let you log in and review things in a paused state on the container.
I also noticed the following lines, which may be unrelated to the report issue, but I wanted to mention them just in case:
From that error, it seems like whatever driver that is trying to be loaded here is not working as expected, so I’d recommend investigating how you have things configured on the machine that is doing this work.
I also found a lengthy GitHub post on the same issue, which had a few different things to try for this. The latest comment is fairly new and may be helpful in resolving this, for example:
The other line:
13:49:33 Error | [220:0202/134239.972466:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
For this, I found the following GitHub post that seemed relevant:
The last comment links to a Medium post on setting up automated testing, which might also include some helpful information:
I hope this additional information helps, but let me know what you find out and we’d be happy to help further.
Thank you so much on the suggestions provided. I have worked on issues:
Permission denied is fixed and working now.
GPU memory and Libva error - are outstanding(which I will work in next few weeks) and don’t see they might be the cause for the deployment failure.
Current issue is my tests are run and individual spec file mochawesome.html files are getting created along with assets folder, but the merged html is not getting created. Sending the logs for this run.
Great news you got the permission denied error fixed, and good to note about the GPU memory and Libva error.
For the current issue on the html files being created along with the assets folder not many of us on shift this morning are well versed in this area unfortunately and it looks like Britton and Kenny have done some work on this already with you so I will message Britton who comes online with the US team a bit later on (around 2 to 3pm UK time).
I will get him to look into this for you as we would rather have continuity with this issue to get you the best possible help and advice. I just wanted to message to say we will get to your issue and we did not want to leave you with no response for a few hours.
Hopefully Britton can get to the bottom of this later on for you.
Reach out in the meantime if you have any other thoughts on this issue or you find something new when you run your testing.
Thank you for your patience while I took a deeper dive into this.
In reviewing the latest log, I noticed the following line (line 12989):
17:55:40 Error | /etc/octopus/Cypress-worker/Work/xx/Script.sh: line 11: /Cypress/node_modules/inline-assets/bin/inline-assets.js: No such file or directory
And in looking up further in the task log, I see this line:
Given these messages, it seems like something might be off with the inline-assets node module you are trying to use for bundling these assets.
I’d recommend checking to see if this module is installing as expected in your process, and you can also manually inspect the working directory using the methods I mentioned previously (i.e. by using the Octopus.Calamari.CopyWorkingDirectoryIncludingKeyTo special variable, or by adding a sleep step to your process).
I hope this helps get things going, but let me know if I can be of any more help.
With further investigation, could resolve all the errors and the deployment is now successful, however the merged selfcontained.html is blank always, whilst creating the individual mochawesome.html, mocawesome_001.html and assets directory.
Thank you for the update, and I’m happy to hear you were able to make some progress on this!
In taking a look at the new log, everything looks clear from an error/warning perspective, so you should be all set there.
With the final selfcontained.html file having issues, I would imagine the problem has to do with this line of code, where you are combining everything:
In taking a look at the documentation for the inline-assets Node module, the syntax they use for the CLI command looks slightly different in that the sample doesn’t mention anything about redirecting output (i.e. > selfcontained.html):
So I’d recommend investigating this to see if another syntax works as expected as a next step towards getting things up and running in your process. I wasn’t able to find any concrete examples of this syntax other than the sample I linked above, so you may just need to experiment with this manually and confirm the outputs you are getting.
I hope this helps, but feel free to reach back out if you have any other questions.
