I'm programmatically creating virtual displays with headless, to be used with selenium tests
It doesn't work because headless keeps spawning displays with new ids, every time I run it. It works if before I start my test I run this with the display id I expect headless to generate
export DISPLAY=:[num]
It's obviously not reliable because if the program restarts it's going to use a new id.
I've tried passing a specific id like the headless docs show and it worked! But only the first time, haha
I don't see xvfb processes hanging after my node process quits.
I also tried node-xvfb with worse results.
I'll link to the libraries I used as soon as I get to a computer
Related
Im using k6/x/browser and while running in headed mode my interactions with the browser has no issues
However when I want to use headless mode (because I want to run multiple concurrent vus) then i run in to issues and that interactions with the browser doesnt want to happen
Any ideas on how I can run in headless mode using multiple concurrent vus?
I am using task to run various build steps in parallel. It is like 1000% faster then doing it all synchronously. However, it seems that task uses all these different subshells. I want to be able to prompt the user for their input using a node program. However, when node logs and attempts to prompt from task its restamped with tasks logger and I cannot get the fancy node prompt to show up.
I was wondering what the best way of solving this would be. Ideally, I could use a one-liner that attaches whatever code task runs to the main terminal Window so that the node script can do its thing. However, if that's not possible I'm open to other ideas. I was thinking of creating a bash alias for task that is the front end and then I could post the messages I want logged while node is listening to the socket that task posts onto. I just want to make sure there is no easy way of handling this before I create a custom solution.
Thanks.
I'm newbie using GCP and his Compute Engine Service. I've deploy a Linux Ubuntu Image an it's running like a charm, but I have a issue running Node JS backend.
Let me explain it better:
I'm connecting using Web Browser SSH terminal or GCloud Shell ssh, and it way works running node app.js my backend starts working. But after a time, the sessions stop and my backend service stop working as well. At this time every time when I need to work have to re-activate the service each time.
How could I do for this service works in background and not depends that my ssh terminal are opened?
Thanks a lot in advance.
What actually happen is you are starting your nodejs application using an client which is parent process. So if after sometime the connection is lost of some xyz seconds the parent process dies killing your node application. Now what you can do is use screen. On ubuntu you would do something like this.
sudo apt-get install screen
after successful install run the screen command. Now you will be thrown a brand new terminal. Here you can run your nodejs code which will never die. Since screen runs your application in background. More information here
A good solution could be to use a startup script. To insert a startup script into your already created instance you need to go to this link [1]. When you have your startup script inserted in the metadata field you just need to restart your Instance and then should work perfectly without depending of the ssh session.
[1] https://cloud.google.com/compute/docs/startupscript#startupscriptrunninginstances
I've created this npm package, to make your node app run as a service on your linux machine. Please try it out.
It creates a systemctl service on your machine and runs it as a background service.
I'm having a slightly weird, repeatable, but unexplainable problem with screen.
I'm using ansible/vagrant to build a consistent dev environment for my company, and as a slightly showy finishing touch it starts the dev server running in a screen session so the frontend devs don't need to bother logging in and manually starting the process, but backend devs can log in and take control.
However, one of the systems - despite being built from scratch - ends up with an immediately dead screen (it doesn't log anything to screenlog). Running the command manually works fine.
(the command being)
screen -L -d -m bash -c /home/vagrant/run_screen_server.sh
I've even gone to the point of nuking everything vagrant/virtualbox related on the system, making sure it's installing a clean, nightly box. Exactly the same source box works all the other machines.
Are there any other debugging steps I can be taking or is there something I'm missing?
I'm right now trying to do the same with my setup and hit the same problem.
Further testing has shown, that sleep 1 right after calling the screen helped. It seems the ssh script that ansible calls exits before the screen call is fully detached (or something else, that would explain that the sleep 1 helps)
I've also found Can't get Fabric's detached screen session example to work with the same suggestion.
I need to handle authenticated multiple users running parallel tests on the selenium standalone server, and discovered two webdriver clients on nodejs. There's webdriver-js and wd-js. Which is more active and reliable? Any experiences? I'm a bit concerned about them breaking down when node or selenium updates or removes features.
I don't think any of those packages mention automatically starting Xvfb on a unique display number per test. So start shell commands to run xvfb before driving the browser?
The following process is what I am trying to build in nodejs (it's essentially like Grid 2 but on nodejs purpose of continuous integration of tests running) and looking for any packages or suggestions for any of the following part.
First authenticate the user(s) using a persistent bi-directional connection (WebSockets or HTTP 1.1)
Start/queue tests requested to run by the user on available hardware nodes (I will add more linux boxes so need a package to distribute parallel tests across the "grid")
Monitor the running selenium browser tests and send client status updates (ex) running/stop)
Tests submitted by the users need to be persistent and accessible for future or continuous integration (couchdb or mysql)
Scheduling of jobs to be run on a continuous basis (ex. run every set interval of time).
Is nodejs a bit overkill? should I focus on Java only for the backside?
https://github.com/LearnBoost/soda
This is for vanilla Sauce Labs/Selenium RC integration. I'd imagine when you're running in a browser instance like Selenium RC, websockets should just work, as the javascript on the page is executed. If you're authenticating a user, you want to just fill out whatever form and submit (which triggers your WS auth) as normal.
I don't think nodejs is overkill for this. Node is lightweight. I don't know that I'd add node to my stack ONLY for this, but its certainly convenient and if you have a commitment to javascript, its no big deal.