I am writing an end-to-end test (jest-runner) with Playwright where I spawn my ui, backend and db with Docker Compose. It works well on my local machine but when I ran the same test in the Gitlab, it fails.
After debugging using screenshots, docker container logs and playwright logs I see the following ->
After the domcontentloaded event is fired, the commit event is not fired.
The screenshot shows a blank page.
The correct files were served by the ui container (there is no connectivity problem)
2023-02-06T17:18:51.101Z pw:api <= page.goto succeeded 2023-02-06T17:18:51.103Z pw:api "domcontentloaded" event fired 2023-02-06T17:18:51.338Z pw:api "networkidle" event fired
Any help is appreciated.
I checked the docker container logs, the playwright logs and screenshots.
Related
i want to use the "Mock Server" feature provided with https://restbird.org/ .
When starting restbird via the provided docker image, it listens on localhost:8080 by default.
Unfortunately the configured "Mock Server" instances still need to be started via the Web Frontend as it is described in the documentation here:
https://restbird.org/docs/mock-run.html#run-mock-server
Is there a way to automatically start the "Mock Server" instances when running the docker image without logging in into the backend (via admin/admin) and clicking the "start" button ?
Reason is, i want to start the mock server inside a gitlab pipeline where i have no further interaction possibilities after the container has been started.
I can not find anything like this in the documentation.
Thanks a lot for any clues - or if it is not possible i cam make a feature request.
I have found the solution myself. One can start a specific Mock Server as described in:
https://restbird.org/docs/API-MockServer.html#start-specific-mockserver-case
This can be scripted into my pipeline after executing the docker run command.
I have very bad experience with using Kubernetes dashboard in Azure installed by this tutorial. It becomes unresponsive all the time. The reasons vary:
When you do not touch the dashboard for couple minutes, it becomes unresponsive.
When you open a live log feed from a pod, the parent dashboard browser tab becomes unresponsive.
When you open an exec terminal in a pod, it becomes unresponsive at the very momenty I close the web terminal window.
Sometimes it just stops working in a middle of browsing.
Definig "unresponsive": The dashboard seems alive but when you click anything, nothing happens. Browser reloads the page but there is still the same content even if you click on different menu item.
I'm running the dashboard with a command from MSFT wiki:
az aks browse -g <cluster RG> -n <cluster name>
In the effect you have to re-run az aks browse every wonderful minute. Yes, you still can use it. But its very frustrating and its really a pain in the *** when you have to restart the az aks browse process every time after you use it for one purpose.
When the frontend goes down, the console log is full of this messages, like:
E1106 00:08:08.555527 2927 portforward.go:400] an error occurred forwarding 8001 -> 9090: error forwarding port 9090 to pod XXXXXX, uid : exit status 1: 2019/11/05 23:08:08 socat[31975] E connect(6, AF=2 127.0.0.1:9090, 16): Connection refused
Do you have similar experince?
Is there something that I can do about it?
OSX 10.14.6
I have gone through all the steps and actually logged into the boards app from
wolkenkit-boards
The app starts fine and I can login but the page keeps refreshing at http://local.wolkenkit.io:8080
Has anyone same had the same experience ?
I found out that the docker containers had to be restarted by running
npx wolkenkit start
again and then and only then running the frontend. Otherwise if the certificate is added after the backend is already running the backend sees no authentication and the frontend does so it keeps re-rendering.
I have a machine setup to run automated tests. I have some software, including Fiddler running as scheduled tasks on start up without user required to log in.
But tests fail, since traffic is not going through Fiddler. When I log in to that machine, I can see in Task Manager Fiddler running as background process.
I've tried starting the task as my user and as System.
Trying to figure out how to have traffic go through that fiddler instance. Thank you!
4/27 Update
So it had to do with the user that scheduled task was set to run from. After playing with it, I figured my user was set incorrectly. Now it looks like traffic goes through Fiddler, as tests are passing. But nowhere I can see the traffic. Fiddler is running as background process and I can't find the folder where it stores temp files. I have also tried setting autosave to a file every 5 minutes. And while it works when I run fiddler in UI, no sessions are saved when it runs as background process.
I've setup a Eclipse kepler (v4.3.2) with Chromium JavaScript Remote Debugger to be able to remote debug a node.js process (Connect to V8Debugger).
Then I have started protractor with
node --debug-brk protractor.js conf.js
Where protractor.js is the shellscript file inside the bin folder of the node_module protractor directory missing the first line which starts node.
So node is then startet in debug mode listening on port 5858 for debugger connection.
Inside eclipse I have configured a Standalone V8 VM Debugger Configuration for connecting on local port 5858.
After connecting to the node.js server it hits the first breakpoint inside the protractor.js file.
But when resuming/continue execution it repeats "debugger listening on port 5858" inside the console and do not continue with testing.
Can someone tell me what's the problem with this?
Regards,
Sebastian
Ok here is the answer:
How to debug Node.JS child forked process?
In Short: It is a bug in node.js v0.10 where it is impossible to debug child processes.
But it is still possible to debug the childprocess also:
And as a amendment here is my solution:
Change the code inside launcher.js to fork the childprocess with --debug-brk also! And give it a unique port as explained in the posted link above.
Then you need to set a breakpoint (or put debugger; inside the code) before the childFork.process.send('run',...) function to stop the code from sending the message to the forked process.
This is needed because you have stopped the childprocess from running by setting --debug-brk. So connect to the second process and hit continue. You will see that the childprocess (runFromLauncher) will wait until message 'run' is received. and so switch back to the first debugger, hit run and let it send the message to the childprocess.
You will see, if you set a breakpoint inside the process.on.message(...) function in runFromLauncher.js, you can step through the code again.