I'm using Xcode Continuous Integration for making builds.
OS X Server 4.1,
Mac OS X 10.10.4,
Xcode 6.3.1
My all test cases start failing after OS X update OS X 10.10.4 (Build 14E17e) and Xcode 6.3.2. I'm not sure whether these update cause the issue or something else.
Error: Bot Issue: error. Uncategorized. Issue: Test target MyTests encountered an error (Test session exited(0) without checking in
Any idea what is the cause of the issue?
Observation:
I ran test cases using xctool all the test cases are passing however when I ran test cases in release mode, they are failing.
My issue is resolved. I don't know the exact reason however I changed sign-in '-' to Don't SignIn in build setting of all tests targets and I found one crash while running test cases in released mode. My issue is resolved after fixing these two issues.
Related
I'm using Comma IDE features for the first time.
I have a very simple test file. Comma is showing warnings for the subroutines provided by the Test module with a report Subroutine X is not declared.
The tests pass fine. But I'd like to know if I have something misconfigured or if this might be a bug.
I'm using the 2022.01 version (Community Edition), Build #CT-213.5744. (jan 30, 2022) with Runtime version: 11.0.13+7-b1751.19 x86_64 and VM of Dynamic Code Evolution 64-Bit Server VM by JetBrains s.r.o. If it matters, the Java installed on my machine is build 1.8.0_321-b07, Version 8, Update 321.
Similar to the answer at Subroutine 'say' is not declared on CommaIde, a simple restart of IntelliJ ultimately fixed the issue.
However, initially, a simple restart did not fix the problem for me. During that first attempt, I was prompted to select the SDK again (for reasons unknown to me). So it looks to me like that whenever you select an SDK, you'll need to close and reopen IntelliJ before IntelliJ will properly load modules provided by the SDK (Rakudo/Moar VM).
Caused by: java.lang.IllegalStateException: Unable to complete the scan for annotations for web application [] due to a StackOverflowError. Possible root causes include a too low setting for -Xss and illegal cyclic inheritance dependencies. The class hierarchy being processed was [org.bouncycastle.asn1.ASN1EncodableVector->org.bouncycastle.asn1.DEREncodableVector->org.bouncycastle.asn1.ASN1EncodableVector]
at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:2104)
at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2048)
at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1994)
at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1964)
at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1917)
...
I am new to the Spring framework.
Here is the error message. Sometimes it can run while after stopping the project and re-run it, these messages are shown (but if I leave the IDE along for 5-10 mins, it can be run without errors).
What exactly is happening here? I am using the newest IDEA and Tomcat 8.
Solved. The reason is I was using a different version of Tomcat, version 8, while somehow the code is using version 7.
I am using macOS Mojave. On Windows, the code can be run via different versions, however, it seems that on macOS the version matters.
I was wondering why my NUnit tests were suddenly terminating successfully after 30 seconds whereas they usually take at least 20 minutes. Then I looked into the build log and found that after upgrading the mono version on our build agent to v 5.4.1, the test runner crashed with exit code 134.
After doing some research, I found out the following:
- The test runner works when using mono 4.8.1 (which we have installed, too), but the test code won't compile with it
- Ì also tried launching th erunner manually like so: /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v /Applications/TeamCity/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe which gave me the following error: [1] 3461 abort /Library/Frameworks/Mono.framework/Versions/5.4.1/bin/mono -v with the 3461changing every time I retry.
- According to this thread, exit code 134 means that the program crashed.
Due to the error output, I am not sure, whether it's the TeamCity test runner that crashes, mono that crashes or TeamCity that makes mono crash.
Any help appreciated :)
I finally figured it out myself. Apparently, Mono 5.4.1 lacks important NUnit2 components that were shipped with Mono 5.2 and older. To make tests work again, I had to add the NUnit.Console NuGet-package (not NUnit.ConsoleRunner as it lacks required extensions) and update the TeamCity build step to use the nunit3-console as described here.
For others that may come across this, I fixed this by changing the NUnit build steps from NUNit 2.6.3 to the NUnit 3.10. I didn't change any of my code / packages, just the TC configuration.
I seem to be having issues with integrating Xcode6 with jenkins, I currently have this setup and working with Xcode 5.
With xcode 6 running remotely via SSH the simulator time-out, when I run locally it succeeds.
Command
xcodebuild -workspace PROJECTNAME.xcworkspace -scheme BGO_Tests -destination 'platform=iOS Simulator,name=iPhone 5s' -derivedDataPath ./Build clean test
2014-08-19 10:46:36.591 xcodebuild[33966:381f] iPhoneSimulator: Timed out waiting 120 seconds for >simulator to boot, current state is 1.
Testing failed:
Test target BGO_Tests encountered an error (Timed out waiting 120 seconds for simulator to boot, current state is 1
Tested with recent Xcode 6 beta 6
Note: the device names changed in Xcode 7, so you no longer specify them using iPhone 5 (9.1 Simulator) but rather iPhone 5 (9.1).
Use xcrun instruments -s to get the current list of devices and then you can pre-launch it using:
xcrun instruments -w "iPhone 5 (9.1)" || echo "(Pre)Launched the simulator."
Prelaunching
I got to a point where what I proposed down there wasn't working anymore. In addition to making the changes mentioned here, you need to launch the simulator xcodebuild is expecting BEFORE xcodebuild is ran:
# First get the UDID you need
xcrun instruments -s
# Then launch it
open -a "iOS Simulator" --args -CurrentDeviceUDID <sim device UDID>
# and wait some time....
sleep 5
# Then launch your unit tests
xcodebuild [...] -destination 'platform=iOS Simulator,name=<device name matching the UDID>'
Old post
This bug is fixed in Xcode 6.3 and above. If you are experiencing similar problems in newer Xcode, it's likely another bug.
Apple follow up regarding Bug ID# 18001199:
The context provided by LaunchDaemons is not supported for running GUI
applications. The SSH service, and the default setup for Jenkins, are
both implemented as LaunchDaemons. In earlier versions of Xcode 5
xcodebuild could run tests on the iOS simulator in this context, but
that was never a supported configuration, and as you have noted that
is no longer working as of Xcode 6.
Unlike LaunchDaemons, LaunchAgents provide a context where you can run
GUI applications - if the user is logged in at the time, with a window
server / Aqua session. Converting your Jenkins configuration from
being a LaunchDaemon to being a LaunchAgent would avoid the reported
issue. You can also use launchd for running tests on the iOS simulator
from a SSH session, either by crafting a LaunchAgent and manually
loading / starting that, or by using "launchctl submit”.
Ok, after some more digging around the comments around here (many thanks to Opal), I found out that launching the slave via JNLP instead works.
As many people mentioned, it is not currently possible to run the unit test over SSH, so you might want to turn towards the JNLP agent for now until Apple fixes it.
If connecting with JNLP still does not solve it, try the solution mentioned in this comment.
i.e.: Run these on command line:
DevToolsSecurity -enable
sudo dscl . -append /Groups/_developer GroupMembership "user-that-runs-the-sim"
security authorizationdb write system.privilege.taskport is-developer
See References here and here.
I've recently found out that if you install a new version of Xcode and do not launch it. The simulator might start timing out again. To solve this, I've had to manually launch Xcode, and install the additional tools it requested.
I ended up solving this on Xcode 5 by doing the steps here, essentially running:
sudo security authorizationdb write system.privilege.taskport allow
This will eliminate one class of these authentication popups. You’ll also need to run:
sudo DevToolsSecurity -enable
However, once I upgraded to Xcode 6, I now get an infinite hang when trying to run xcodebuild tests over SSH. They continue to run just fine as long as I'm logged into the console, and running them from the keyboard.
I ran into the same issue. My working theory is that SSH on OSX is started as a LaunchDaemon, and LaunchDaemons are not allowed to present a UI; Reference.
I was able to work around the issue by using Java Web Start to launch the Jenkins slave. I then installed the Jenkins slave as a launchd service.
Unfortunately the Jenkins slave then installs itself as a -you've guessed it- LaunchDaemon, leading to the exact same problem of not being able to launch the tests; Reference.
I worked around that issue by moving the Jenkins Slave LaunchDaemon plist and jar files in /System/Library/LaunchDaemons into ~/Library/LaunchAgents, and updated the paths inside the plist file.
That finally allowed me to run XCode6 (Beta6) tests on an OSX jenkins slave.
I finally managed to find a good simple solution. JNLP was causing numerous issues with our jenkins server.
Workaround for SSH timeout via https://corner.squareup.com/2015/07/ios-build-infrastructure.html
"Mavericks (10.9) and Yosemite (10.10) determine if a process can access accessibility hooks via the parentage of the accessing process. By putting launchd in the list of allowed processes, processes launched via SSH or Jenkins have access to the accessibility hooks across the system. To do this you can modify the TCC database, per this gist. A reboot is required to make the change take effect."
#!/bin/bash
# This will add lauchd to the list of allowed processes for accessibility access
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db "INSERT or REPLACE INTO access VALUES('kTCCServiceAccessibility','/sbin/launchd',1,1,1,NULL)"
# This outputs the rows in the TCC database
sudo sqlite3 /Library/Application\ Support/com.apple.TCC/TCC.db 'select * from access'
echo "Restart is required for these changes to take effect"
Update 8/02/2016
This is now fixed in Xcode 7.2.1 ("Command line tool ‘xcodebuild test’ will no longer time out waiting for Simulator.app to launch")
I've seen this error before, one possibility is that since you probably downloaded the Xcode6 Beta from the internet (not the appstore as its not available yet), the machine you are trying to run it on will show a pop up asking you if you really want to open this app as its from the internet.
The same will happen when xcodebuild tries to launch the iPhone simulator app.
One thing you might want to try is to share screen with the machine and click "Open" in that pop up.
If that still doesn't work, I would try to:
Reset the Content & Settings of the simulator
Reboot the machine and make sure no simulator is running on start up (you can just choose not to re-open any app when restarting)
I'm developing a solution for Windows CE 6.0 using GuD_AtomKit X86 Device emulator.
I'm not able to run any unit tests, because I get following error message:
The test adapter ('Microsoft.VisualStudio.TestTools.TestTypes.Unit.UnitTestAdapter, Microsoft.VisualStudio.QualityTools.Tips.UnitTest.Adapter, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a') required to execute this test could not be loaded. Check that the test adapter is installed properly. Exception of type 'Microsoft.VisualStudio.SmartDevice.TestHostAdapter.DeviceAgent.TestAlreadyRunningException' was thrown.
But there's no unit test running on the device.
I would really appreciate your help.
Did you change the target device in your testrunconfig file? Running against the target device is definitely supported.
You also might have to manually deploy the CF to the device as the Unit Test framework doesn't auto-deploy it.
That was probably caused by a hardware issue. After I updated the flash with the board I was running the test against, it started to work again. So probably a bug in the firmware of the board... :(