IOS CI workflow

[harishthakur52]

1. Installing cocoapods in system.
2. Testing compatibilty with packages versions.

[Copilot]

Pull request overview

Adds a GitHub Actions workflow intended to provide iOS CI around CocoaPods setup for the ios/OpenBot project.

Changes:

• Introduces a new workflow triggered on changes under ios/OpenBot/** and the workflow file itself.
• Adds steps to install CocoaPods and run pod install from ios/OpenBot.
• Forces regeneration of dependencies by deleting Podfile.lock before install.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The workflow header says it “builds and tests the iOS app”, but the job currently only runs pod install and never invokes Xcode to build or run tests. This means CI can still be green even if the Xcode project/workspace is broken. Consider adding an explicit Xcode build/test step (e.g., xcodebuild for the workspace + scheme, optionally against a simulator destination) so the workflow actually validates build configuration as described in the PR.

[Copilot]

sudo gem install cocoapods installs the latest CocoaPods at runtime, which can make the workflow flaky over time (behavior changes between CocoaPods releases) and slows every run. Consider pinning the CocoaPods version (or using Bundler with a Gemfile/Gemfile.lock and ruby/setup-ruby with bundler-cache) to make CI reproducible and faster.

Suggested change

	run: sudo gem install cocoapods
	- name: Remove Podfile.lock (regenerate)
	run: rm -f Podfile.lock
	- name: Pod install
	run: pod install
	run: sudo gem install cocoapods -v 1.15.2
	- name: Remove Podfile.lock (regenerate)
	run: rm -f Podfile.lock
	- name: Pod install
	run: pod _1.15.2_ install

[Copilot]

Removing Podfile.lock forces dependency re-resolution on every CI run, which makes builds non-deterministic and can hide issues that only occur with the locked dependency set. If the goal is deterministic CI, commit Podfile.lock and use a deployment-style install; if the goal is “compatibility with latest pods”, consider making that a separate, explicitly-named job so it doesn’t replace the baseline check.

Suggested change

	- name: Remove Podfile.lock (regenerate)
	run: rm -f Podfile.lock
	- name: Pod install
	run: pod install
	- name: Pod install (deployment)
	run: pod install --deployment

[thias15]

Fully tested and ready to merge?

[harishthakur52]

Yes , tested and ready

[thias15]

Overall: I'd second the Copilot review's three points — they're real issues even though the PR is approved:

1. The workflow doesn't actually build the app. The file header says "builds and tests the iOS app" but no xcodebuild step exists, so a broken Xcode project/scheme/signing config will still pass CI. Consider adding xcodebuild -workspace OpenBot.xcworkspace -scheme OpenBot -destination 'generic/platform=iOS Simulator' build (or similar) — otherwise this only validates that pods install, which is much narrower than the name implies.
2. Pinning CocoaPods is worth doing. sudo gem install cocoapods (no version) means a new CocoaPods release can spontaneously break CI without any code change.
3. Deleting Podfile.lock makes CI non-deterministic. If the goal is to ensure the lock matches reality, pod install --deployment (which fails when the lock is stale) is more useful than blowing it away. The current approach hides drift instead of catching it.

Happy to merge as a starting point if you'd rather iterate later, but (1) in particular reduces the value of this CI a lot.

[harishthakur52]

For actually building the app on a simulator, we need to store our Apple team certificates and provisioning profile secrets and use them during the build process.

But as a starting point, I think we can merge this.