We are using Jenkins to run our xcodebuilds on a Mac Mini server. In the last weeks we started development of iOS 7 apps and we installed Xcode 5 DP versions on the Mac Mini.
When installing a new Xcode version and configuring the xcodebuild of the new Xcode which xcode-select this new version is also used for building our old iOS 6 apps - which breaks the UI of them.
Is there a way to tell Jenkins which xcodebuild it should use to build a project?
Check out the solution posted by Andy Molloy at http://andymolloy.net/specifying-xcode-version-for-jenkins-projects.
You have to install EnvInject plugin for Jenkins and add DEVELOPER_DIR=/Applications/Xcode5-DP6.app/Contents/Developer environment variable to your build job.
It doesn't look like it is possible to specify xcode version per jenkins job. Also switching xcode version on the command line requires root permissions.
You might manage to solve your issue by making sure your IOS 6 apps, when built with the new xcode, work properly. Try selecting the proper base SDK and deployment target http://www.clarkcox.com/blog/2009/06/23/sdks-and-deployment-targets/
If that won't work you could try forcing a switch of the xcode version to use at build time, pre xcode plugin use. You will have to fiddle with sudo rights. Given that this is a system setting, you might need to prevent multiple builds from happening simultaneously.
I would do my best getting the multiple builds working with a single xcode version though.
Select the xcode version at runtime
Use EnvInject plugin
for jobs that require the non default do something like
DEVELOPER_DIR=/Applications/Xcode6.0.1.app/Contents/Developer
under Inject environment variables to the build process
https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin
Related
Xcode 11 has changed the way that versions are handled.
So far I had two targets, Dev & Prod, each with a separate versions. Prod version would be entirely manual, Dev would be automated:
During a build, a script would run, which then would fetch git tags. One tag would contain information about the latest Dev version. If it's newer, it would update version inside Info.plist just for the Dev target
When Dev would be deployed using a script (create an ipa, resign for in-house distribution, upload), the build version would then be increased. Remote tag containing version information would then be updated
In this way everyone's dev version would get automatically synchronized and managing multiple dev builds would be be easy. Prod would be updated relatively infrequently so it can be managed manually.
However, in Xcode 11 whenver version (or build) is updated inside the General tab, entries in Info.plist are replaced with $(CURRENT_PROJECT_VERSION) and $(MARKETING_VERSION) and Current Project Version and Marketing Version inside the build settings tab is used instead.
So far I would use PlistBuddy in order to read and update versions inside Info.plist, but from what understand now I'd have to use agvtool. However, there are two issues with it:
If it's ran as a Run Script phase, it causes the build process to cancel
It is unable to handle separate versions for two targets (so I cannot just automatically manage Dev, while leaving Prod alone)
I know that theoretically I can still use Info.plist for versioning, but the moment someone changes version manually in the General tab, the whole thing will get messed up (from experience I know that this will happen).
I have two questions:
Is my understanding of the process correct?
Can still have a version management system using agvtool similar to what I had before?
I want to update an existing Android app (not made with NativeScript), with a new one (made with NativeScript).
The old app stored some user data in a SQLite database. I want this to survive the upgrade.
Now, I have the same app-id in the new app, as the old, so that part is in place. To test if the database survives though, I have started the Android Emulator with the old app, created a few records, then published the native script version using
tns run android --bundle --device=1
and this correctly replaces the old app with the new code, but at the same time it seems to wipe the database, which is otherwise correctly stored in /data/data/app-id/databases
Is this due to the tns deployment for debugging possibly starting out wiping the system, or something else ?
How do you guys test this?
Edit: Apparently the uninstalling after each compile, rather than upgrading is a known thing, tracked in their Github as issue #3382
tns run android --bundle produces a development version of APK which would not match the signature of your production version of APK built with native Android.
If you use the same signing certificate you used for the production native app while running app / building your {N} version of APK, then you will survive the upgrade by default.
So your command may look like
tns [build|run] android --bundle --release --keyStorePath /path/to/keystore --keyStorePassword keystore-password --keyStoreAlias keystore-alias --keyStoreAliasPassword keystore-alias-passwrd
Read more on docs.
Edit: CLI seems to have a known issue with tns run, instead of replacing the APK, it deletes the old version and installs new version. So it should not be a problem when you publish the APK built with tns build. Credits to #DimitarTachev.
I have attempted to archive my project for submission to App Store, however, every time I get errors "use of undeclared identifier" for everything related to google iOS SDK. The application itself runs and builds flawlessly with the discussed SDK integrated, the only thing that fails is the archive process. I have tried both cocoa pods and manual method of integration (separately, of course). Furthermore, I used the latest xCode versions (6.4 and 7 beta 4) on two different macs running OS X 10.10.4. This is the guide I have been using.
Your issue has something to do with the configuration of archiving in combination with your Release settings. If you change the scheme settings Command + < to use the Debug configuration for archiving, you may be able to successfully archive your app. This means that somewhere you are probably not matching the Debug and Release configurations.
See the following screenshot for example project Build Settings that are missing the Swift bridging header in release:
Add bridge.h to the release configuration and you will be able to build with the Release schema and you will be able to archive under release configuration.
I've got TeamCity installed and working, and I need to have a build step run on a particular build agent (everything's running on Windows, but we have a Mac portion I need to build as well).
How do I tell the build step what agent I want it to run on? I've seen this, but that references an entire build; I just want a particular step to run on a given agent.
Is this even possible?
From what I am aware of, it is not possible. You may want a separate build configuration to build for mac.
Sharma is somewhat correct, and KIR has it completely correct.
I needed a build configuration for each server, Mac and Windows. Then I set a snapshot dependency from the Windows build on the Mac build (to make sure the Mac version builds completely first) and a artifact dependency from the same (to copy the resulting build output from the Mac to the Windows box). Then I modified the build process on the Windows box to include the artifacts, and voila, works like a charm.
We're considering migrating from CruiseControl/CruiseControl.NET to TeamCity.
A portion of our product is a Cocoa app, and I need to figure out if I want to try to migrate it to TeamCity as well, or if it would be better to leave it running under CruiseControl.
Everything I've found so far (including the teamcity-xcode plugin) refers to running xcodebuild under TeamCity 4.x, but we're running 5.x.
Is it possible to run an Xcode build under TeamCity 5.0?
What were your experiences?
We're currently looking into that as well, hence my googling bringing up this question. According to the docs TeamCity can run agents on OSX and this blog post discusses getting an iPhone build up and running. Hopefully these will prove a good starting point to getting an iOS build under TC.