I've successfully run IOS UI Automation Instruments from command line on my local Mac. When it starts to test, the simulator will automatically pop up and then do the stuff.
However, when I SSH to a build server (with OSX and xcode, will use Jenkins eventually) and try to do the same thing, it doesn't work well.
Building process is fine, but as long as I run instruments, the terminal will then hang there without doing anything. I figure it has something to do with iphone simulator GUI but since it's CLI, I don't know what's going on...
Do you guys have any idea? Thanks!!
.
After executing the command from Jenkins through SSH; in most cases you would see a pop up window as in the screen shot. You will have to get past this screen to execute your tests. This post addresses how to get past that issue Stop "developer tools access needs to take control of another process for debugging to continue" alert
I've had the same issue. instruments -w "$DEVICE" were ignoring parameters.
Same with
DEVICE_TARGET='iPhone 6 (8.1 Simulator)' cucumber --format json -o test-reports/cucumber-8.1-iphone.json
It were ignoring DEVICE_TARGET parameter.
Solved via running Jenkins slave NOT as a SSH slave but as the Slave agent via java web start
http://i.stack.imgur.com/lNlPA.png
As i understand this issue is caused by OS X launchagent that managing sshd and performs scope of restrictions for remote users.
IMPORTANT! Slave agent should be started from OS X desktop, not via ssh! I've connected via VNC and launched slave java web agent on the OS X UI terminal.
Related
Hi I have an macOS Application which needs to be configured for CI/CD purpose on the Jenkins.
I need to run the test cases before making the application available for the distribution or before creating a package file.
I am using the below mentioned command
xcodebuild -workspace xxx.xcworkspace -sdk macosx11.3 -scheme xxx -destination "platform=OS X,arch=x86_64" clean test
when I execute this command in the Jenkins it throws me an error
ERROR: The test runner encountered an error (Failed to establish communication with the test runner. If you believe this error represents a bug, please attach the result bundle at /Users/ec2-user/Library/Developer/Xcode/DerivedData/xxx-gkolnyonjdnyixfknefsjvbsyzia/Logs/Test/Run-xxx-2021.05.24_11-58-07-+0000.xcresult. (Underlying Error: Couldn’t communicate with a helper application. Try your operation again. If that fails, quit and relaunch the application and try again. The connection to service on pid 0 named com.apple.testmanagerd.control was invalidated.))
I need to make use of macOS itself to run as a simulator. As Jenkins runs as a Daemon on the ec-2 instance.
NOTE: NOT USING XCODE PLUGIN TO EXECUTE MY COMMANDS
Please help!!!
My MacOS system was a slave and I was running my scripts through the Linux server.
macOS was connected using the SSH earlier then this authentication method was required to be changed to access the UI of the Mac
Test cases running now
Based on observation, macOS Big Sur, Monterey, and probably subsequent versions no longer allow tests to be run through a SSH session. By changing the way Jenkins controller connects to the slave, you can prevent the command from being run through SSH.
The first way, Jenkins built-in, to do this and easiest is to use the JNLP method for agent communication. This will involve running a Jenkins agent on the slave machine that communicates with the Jenkins controller. In the end, the agent on the machine is running the test command rather than through a SSH session.
The second way is to build your own agent. It could be as simple as a file change trigger leading to a script executing. This is only necessary if for some reason the Jenkins slave is not able to connect to the Jenkins controller due to some networking constraints.
I have drone installed on a Mac mini as a CI/CD for Android and iOS apps. To build for iOS I need to run commands on the server itself. I know there is a ssh plugin, but is there another way to run commands on the host from a drone pipeline step?
I would suggest taking a look at the exec runner, sounds like exactly what you would need.
The Exec runner executes build pipelines directly on the host machine without isolation, using the default shell. This runner is not suitable for un-trusted workloads for security reasons.
https://exec-runner.docs.drone.io/
I'm trying to run GoCD on MacOS (10.12) for testing purposes. When I run both the server and the client apps, they do not provide any GUI output (they should show progress bars or a host configuration) and they quit a couple of seconds after starting.
When I try to run the apps from Terminal as:
/Applications/Go\ Server.app/Contents/MacOS/go-server
I get the following output:
Got directory: /Users/taatyyu1/Library/Application Support/Go Server [It exists]
and then the app quits.
How can I discover what is the issue of the apps not starting properly?
The logs of the apps are available in
~/Library/Application\ Support/Go\ Server/osx-app.log
and
~/Library/Application\ Support/Go\ Agent/osx-app.log
They contain the information from apps starting up and you can use them to figure out what goes wrong
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.
When I run my selenium test (mvn test) from jenkins (windows) I see only the console output. I don't see the real browsers getting opened . How can I configure jenkins so that I can see the browsers running the test?
I had the same problem, i got the solution after many attempts.
This solution works ONLY on windows XP
If you are using jenkins as a windows service you need to do the following :
1) In windows service select the service of jenkins
2) Open properties window of the service -> Logon-> enable the checkbox "Allow service to interact with desktop"
After then you should reboot the service jenkins
Hope this help you :)
UPDATE:
Actually, I'm working on a an automation tool using Selenium on Windows 10, I've installed Jenkins ver. 2.207 as windows application (EXE file), it's running as windows service and ALL drivers (Chrome, FireFox, IE) are visible during test executions WITHOUT performing a mere configuration on the System or Jenkins
I got the solution. I ran jenkins from command prompt as "java -jar jenkins.war" instead of the windows installer version. Now I can see my browser based tests being executed.
If you are already doing what #Sachin suggests in a comment (i.e. looking at the machine where Jenkins actually runs) and still do not see the browsers, then your problem may be the following:
If you run Jenkins as a service in the background it won't open apps in the foreground. You may either try to run it not as a service in the foreground, or run it as a Local System account and check Allow the service to interact with desktop option. In the latter case you may get into permission problems, though.
Update: To make sure this answer is understood properly by others: Jenkins Windows 'native' installation is not really native. It's a wrapper around Java that runs it as a service.
To interact with desktop GUI, you should launch slave agent via JNLP:
https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-LaunchslaveagentviaJavaWebStart
After adding the node in Jenkins (configured as Java Web Start launch), just make a startup batch script on the node machine:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
See more answers here:
How to run GUI tests on a jenkins windows slave without remote desktop connection?
In the case of Windows 7 you should not install jenkins as windows application (because in this recent version, Microsoft decided to give services their own hidden desktop even you enable the functionality "interact with desktop" in jenkins service), you may have to deploy it from a war file as follows:
1) Download jenkins.war from Jenkins official site
2) Deploy it by the command prompt : java -jar {directoryOfJenkinsFile}/jenkins.war
3) Now you can access jenkins administration on http:// localhost:8080
Hope that helps you !
this is an issue for Jenkins. on Windows it is possible to access logon user's session (screen) under system account. to make the UI testing visible, Jenkins needs to bypass UAC (user access
control) at background. this solution works for me with my own service running as system account.
I also faced the same issue earlier in my local machine (Windows 10).
My test was running perfectly from the NetBeans but when I moved to Jenkins it was only running in console mode. I was unable to view the UI.
So for that, you just need to make your local machine as a Jenkins slave by creating a new slave node in your Jenkins and select that node to execute the Jenkins job.
If jenkins installed by windows installer it is showing only Console out put only. To see browsers download jenkins.war file and run java -jar jenkins.war from command line.
Go through this site:
http://learnseleniumtesting.com/jenkins-and-continuous-test-execution/
If you have the following situation,
You are able to login to the remote machine
You don't see the Jenkins agent window
This slave machine is accessed by many users then try the following,
then try the following suggestion.
Login to slave machine
Go to Task manager
Users
Logout all the users
Then login again.
This worked for me.