I have a docker setup for nightwatch.js to run selenium tests through selenium grid for an express server application. When I just use a docker-compose up and then run my nightwatch tests manually after the server starts everything appears to start properly. If I run them as part of a containers command (ie. in my app server containers command or in a new container based on it that just runs nightwatch) then I get a 503 bad gateway error. I think there is a race condition in my docker setup that is causing this. Is there a way to guarantee my app server starts properly before running my nightwatch tests?
Prefix your command with wait-for-it.sh script (download it a and put in the image):
command: /wait-for-it.sh theotherservice:PORT -- your-previous-command
wait-for-it.sh will wait to the specified server:port to execute the command that is after --, so you can avoid the race condition.
Related
I have created the Jenkins job to execute the TestCafe tests, the job is working fine.
But I want to execute multiple jobs parallelly.
As TestCafe runs tests on the default port, it is not allowing me to execute jobs parallelly.
Can anyone please suggest how to achieve this?
I tried to execute the jobs parallelly, but its is giving an exception port already in use.
I am not able to change the port in Jenkins job
When starting TestCafe, you can set ports:
https://testcafe.io/documentation/402644/reference/testcafe-api/testcafe/createrunner
https://testcafe.io/documentation/402639/reference/command-line-interface#--ports-port1port2
Use different ports for each parallel task.
I am trying to run apache server on AWS AppRunner using my source code repository with corretto 11 as runtime using the below start command
https://github.com/myanees284/apprunner-jmeter/blob/main/run_apacheee.sh
I could see the commands in the above sh gets executed and service gets deployed successfully as running. However after the deployment and health check, the commands are executed repeatedly.
Application log is here: https://gist.github.com/myanees284/db233e7e0d71eba4643f56c2e1bf87ec#file-application-logs2022-08-22t06_29_55-322z-2022-08-23t06_29_55-322z-json-L281
I am unable to understand why the code is executed multiple times when the service is already running?
After your start script exists, the container stops as well. That's why App Runner starts a new container after
I finally handled that Yii1 and YiiBridge install instructions and run some sample test. The problem now is, instead use my localhost, PHPBrowser is going to an unknown server from LAN, which obviously fails all tests. Is there any configuration that can prevent this?
edit: Refs
https://codeception.com/docs/modules/Yii1.html
https://github.com/Codeception/YiiBridge
We have a situation trying to run jenkins behind apache,
we need to specify a new context path because we already have an instance of jenkins in ./Jenkins, so we try to use the parameter --prefix=/jenkins2/ in order to have the 2 instances separated.
The problem is that with that parameter, when i hit the url http://myserver.com/jenkins2 i have this:
HTTP ERROR 404
Problem accessing /. Reason:
Not Found
Powered by Jetty:// 9.4.z-SNAPSHOT
any help?
In /etc/sysconfig/jenkins or /etc/default/jenkins change the follow line
JENKINS_ARGS=""
to
JENKINS_ARGS="--prefix=/jenkins2"
you can also run in a different por changing JENKINS_PORT in the same file.
Probably yours is not working because the "/" in the end "/jenkins2/"
If you can't find these files, you can check where is viewing the content of /etc/init.d/jenkins, in the line starting with "JENKINS_CONFIG="
If you are not running jenkins as service you can run:
java -jar jenkins.war --prefix=/jenkins2
I have a test system (various web pages / web applications), that is hosted in an environment accessible only via machines with IP addresses that are white listed. I control the white list.
Our CI system is cloud hosted (Gitlab), so VMs are spun up dynamically as needed to run automated integration tests as a part of the build pipeline.
The tests in question use BrowserStack automation to run Selenium based tests, which means the source IP addresses of the BrowserStack automation driven requests that hit the test environment are dynamic, as BS is cloud hosted. Also the IP addresses of our test runner machines that call / invoke the BrowserStack automation are dynamic as well.
The whole system worked fine before the intro of IP white listing on the test environment. Since white listing was enabled, the BrowserStack tests can no longer access the environment URLs (due to not being able to white list the dynamic IPs).
I have been trying to get the CI driven tests working again using BS "Local Testing" feature, outlined here https://www.browserstack.com/local-testing.
I have set-up a dedicated Linux VM with a static IP address (cloud hosted). I have installed and am running the BrowserStackLocal.exe binary, using our BS key. It starts up fine and says it has connected to BrowserStack via a web socket. My understanding is this should cause all http(s) etc requests that come from my CI / BrowserStack automation driven tests to be routed through that stand-alone machine (via BS cloud), resulting in it's static IP address being the source of the requests seen at the test environment. This IP addr is white listed.
This is the command that is running on the dedicated / static IP machine:
BrowserStackLocal.exe --{access key} --verbose 3
I have also tried the below, but it made no apparent difference:
BrowserStackLocal.exe --{access key} --force-local --verbose 3
However, this does not seem to work? Either through "live" testing if I try and access the test env directly through BrowserStack, or through BS automate. In both cases the http(s) requests all time out and cannot access our test environment URLs. Also even with --verbose 3 logging level enabled on the BrowserStackLocal.exe process, I never see any request being logged on the stand-alone / static IP machine when I try to run the tests in various ways.
So I am wondering if this is the correct way to solve this problem? Am I misunderstanding how to do this? Do I need to run the BrowserStackLocal.exe perhaps on the same CI runner machine that is invoking the BS automation? This would be problematic as these have dynamic IPs as well (currently).
Thanks in advance for any help!
EDIT/UPDATE: I managed to get this to work!! (Sort of) - it's just a bit slow. If I run the following command on my existing dedicated / static IP server:
BrowserStackLocal.exe --key {mykey} --force-local --verbose 3
Then on another machine (like my dev laptop) if I hit the BS web driver server http://hub-cloud.browserstack.com/wd/hub, and access the site http://www.whatsmyip.org/ to see what IP address comes back, and it did (eventually) come back with my static IP machines address! The problem though is it was quite slow - 20-30 secs for that one site hit, so still looking at alternative solutions. Note for this to work your test code must set the "local" browserstack capability flag to 'true' - eg for Node.js:
// Input capabilities
var capabilities = {
'browserstack.local' : 'true'
}
UPDATE 2: Turning down the --verbose logging level on the local binary (or leaving that flag off completely) seemed to improve things - I am getting 5-10 sec response times now for each request. That might have to do. But this does work as described.
SOLUTION: I managed to get this to work - it's just a bit slow. If I run the following command on my existing dedicated / static IP server (note adding verbose logging seems to slow things down more, so no --verbose flag used now):
BrowserStackLocal.exe --key {mykey} --force-local
Then on another machine (like my dev laptop) if I hit the BS web driver server http://hub-cloud.browserstack.com/wd/hub, and access the site http://www.whatsmyip.org/ to see what IP address comes back, and it did come back with my static IP machines address. Note for this to work your test code must set the "local" browserstack capability flag to 'true' - eg for Node.js:
// Input capabilities
var capabilities = {
'browserstack.local' : 'true'
}
So while a little slow, that might have to do. But this does work as described.