-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Explore LLVM markers in dylibs re: compatibility with Xamarin Studio < 9.0 and cordova apps #300
Comments
I generated a FAT dylib with no bitcode markers. |
I wonder if we couldn't get a dedicated device host in XTC with a few iOS devices just for being able to do some kind of CI with physical devices (for things of the not-to-be-named variety that must be tested on physical devices). @krukow |
@sapieneptus what's wrong with using the normal XTC interface? |
@krukow I was thinking about finding a way to smoke test things like building/deploying to device, testing different dylibs against physical devices (to test library architecture compatibility) etc... not so much running actual automation tests. We could write a bunch of service containers / pipelines to handle this, but for our CI needs I think it's overkill. Point being, XTC already has some device lifecycle management that I don't think we could get from, say, a hosted Jenkins or something, so if we could just get that functionality on a device host and be able to ssh in and run jobs, that would be nice. Might be an over simplification, but there is a lingering difficulty in smoke testing certain types of physical-device interactions effectively. |
A step in the right direction would be options for selecting devices from the command line. |
To play devil's advocate on that one, you can use the XTC API to get device selection, then use regex or something to find the one you want (say via ruby script). But I still think it's a bit overkill to go through a whole XTC test run when we'd really just be testing, say, that a dylib is compatible with a given app for a physical device. I guess we'll take this offline, but alternatively @jmoody we could do a CI on a mac-mini that someone physically owns. We'd just need to do some error handling for when the thing is off / not available. |
I have never seen this. Can you demonstrate?
This is the kind of thing that I usually do locally. I have most of the iPhone/iPad and iOS versions combinations. I have thought about setting up Jenkins on my network. Let's discuss off line. |
Experiment
The text was updated successfully, but these errors were encountered: