chore(ci): fix iOS builds hanging on Github Actions

[diegolmello]

Proposed changes

Added options to the keychain creation for locking behavior and unlocking. Introduced key partition list settings for improved code signing management.

Issue(s)

https://rocketchat.atlassian.net/browse/CORE-1570

How to test or reproduce

Screenshots

Types of changes

• Bugfix (non-breaking change which fixes an issue)
• Improvement (non-breaking change which improves a current function)
• New feature (non-breaking change which adds functionality)
• Documentation update (if none of the other choices apply)

Checklist

• I have read the CONTRIBUTING doc
• I have signed the CLA
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works (if applicable)
• I have added necessary documentation (if applicable)
• Any dependent changes have been merged and published in downstream modules

Further comments

Summary by CodeRabbit

• Chores
  • Improved iOS build configuration to increase provisioning and signing reliability by explicitly scoping provisioning to iOS.
  • Expanded keychain access and timeout settings to reduce lock interruptions during automated builds and added signing-preparation steps to stabilize the code-signing flow.
  • Minor Gemfile tweak: reordered CocoaPods exclusion entries.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Caution

Review failed

The pull request is closed.

Walkthrough

Keychain creation flags changed (timeout 0, lock_when_sleeps: false, unlock: true); explicit platform: "ios" added to match/get_provisioning_profile calls; security set-key-partition-list / set_key_partition_list commands inserted into iOS signing/provisioning flows. Gemfile: cocoapods exclusion order adjusted.

Changes

Cohort / File(s)	Change Summary
iOS Fastlane Fastfile ios/fastlane/Fastfile	- create_keychain timeout changed from 1200 to 0 and now includes lock_when_sleeps: false and unlock: true. - match(...) and get_provisioning_profile(...) calls in build_experimental and build_official now include platform: "ios". - Inserted keychain access/config commands (security set-key-partition-list / set_key_partition_list and set-keychain-settings / unlock steps) around signing/provisioning steps (before gym in build_experimental; before/around update_code_signing_settings in build_official, with one `
Gemfile Gemfile	- Reordered cocoapods exclusion: != 1.15.1 appears before != 1.15.0. No other gem changes.

Sequence Diagram(s)

sequenceDiagram
  participant CI as CI runner
  participant Fastlane as Fastlane (Fastfile)
  participant Match as match / Apple provisioning
  participant Security as macOS `security` / set-key-partition-list
  participant Gym as gym / build step

  CI->>Fastlane: start build_experimental / build_official
  Fastlane->>Fastlane: create_keychain(timeout:0, unlock:true, lock_when_sleeps:false)
  Fastlane->>Security: set-keychain-settings / unlock keychain
  Fastlane->>Match: match(type:"appstore", platform:"ios")
  Match-->>Fastlane: provisioning profiles & certificates
  Fastlane->>Security: security set-key-partition-list / set_key_partion_list
  Fastlane->>Gym: gym (build/sign with unlocked keychain)
  Gym-->>CI: build artifacts

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

• Verify all match / get_provisioning_profile calls consistently include platform: "ios".
• Confirm create_keychain flags (timeout = 0, lock_when_sleeps, unlock) match intended CI security/locking behavior.
• Check correctness and placement of security set-key-partition-list / set_key_partition_list and set-keychain-settings relative to unlock and signing steps, including the || true usage.

Poem

🐰 I nudged the keys and woke the lane,
I told the profiles their platform name,
I set the partitions, opened the lock,
Builds hop forward—no more blocked clock,
A little rabbit celebrates the lane. 🥕

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main objective of the PR - fixing iOS builds hanging on GitHub Actions through keychain and code signing improvements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

---

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 82609dc and 5008e1a.

⛔ Files ignored due to path filters (1)

• Gemfile.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• Gemfile (1 hunks)
• ios/fastlane/Fastfile (3 hunks)

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

Gemfile (1)

6-6: Cosmetic reordering with no functional impact.

The reordering of version exclusions from != 1.15.0, != 1.15.1 to != 1.15.1, != 1.15.0 doesn't change the effective constraint—both exclude versions 1.15.0 and 1.15.1.

Optionally, consider using ascending order (!= 1.15.0, != 1.15.1) as it's more conventional for version constraints.

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between 174a5d7 and be822c5.

⛔ Files ignored due to path filters (1)

• Gemfile.lock is excluded by !**/*.lock

📒 Files selected for processing (2)

• Gemfile (1 hunks)
• ios/fastlane/Fastfile (3 hunks)

🚧 Files skipped from review as they are similar to previous changes (1)

• ios/fastlane/Fastfile

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: ESLint and Test / run-eslint-and-test
• GitHub Check: format

[coderabbitai]

Actionable comments posted: 2

📜 Review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Jira integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

📥 Commits

Reviewing files that changed from the base of the PR and between be822c5 and 82609dc.

📒 Files selected for processing (1)

• ios/fastlane/Fastfile (3 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: ESLint and Test / run-eslint-and-test
• GitHub Check: format

🔇 Additional comments (2)

ios/fastlane/Fastfile (2)

59-62: LGTM! Explicit platform specification improves clarity.

Adding platform: "ios" to the match and get_provisioning_profile calls makes the configuration more explicit and prevents potential ambiguity.

---

88-92: Document why || true is needed for build_official but not build_experimental.

The set-key-partition-list command on line 92 uses || true to suppress failures, while the identical command in build_experimental (line 68) does not. This asymmetry suggests either:

• The command can fail in specific scenarios only in the official build, or
• Error suppression should also be applied to build_experimental for consistency

Please clarify:

1. Under what conditions does set-key-partition-list fail in the official build?
2. Should build_experimental also use || true for resilience?

If the command failure is expected and safe to ignore, consider adding a comment explaining why, such as:

# set-key-partition-list may fail if the keychain is already configured; safe to ignore
sh "security set-key-partition-list ... || true"

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

Clarify timeout inconsistency between keychain creation and later shell commands.

The keychain is created with timeout: 0 (no automatic lock), but lines 67 and 91 later use security set-keychain-settings -lut 3600 which sets a 3600-second timeout. This creates conflicting timeout configurations.

Consider either:

• Using timeout: 3600 here to match the shell commands, or
• Removing the -lut 3600 flag from lines 67 and 91 to maintain the no-timeout behavior

  create_keychain(	
    name: ENV["MATCH_KEYCHAIN_NAME"],	
    password: ENV["MATCH_KEYCHAIN_PASSWORD"],	
-   timeout: 0,
+   timeout: 3600,
    lock_when_sleeps: false,
    unlock: true
  )

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	create_keychain(
	name: ENV["MATCH_KEYCHAIN_NAME"],
	password: ENV["MATCH_KEYCHAIN_PASSWORD"],
	timeout: 1200
	timeout: 0,
	lock_when_sleeps: false,
	unlock: true
	)
	create_keychain(
	name: ENV["MATCH_KEYCHAIN_NAME"],
	password: ENV["MATCH_KEYCHAIN_PASSWORD"],
	timeout: 3600,
	lock_when_sleeps: false,
	unlock: true
	)

🤖 Prompt for AI Agents

In ios/fastlane/Fastfile around lines 21 to 27 the keychain is created with
timeout: 0 while later shell commands at lines ~67 and ~91 set a 3600s timeout
via security set-keychain-settings -lut 3600, producing conflicting timeout
behavior; to fix, make the timeout consistent by either changing timeout: 0 to
timeout: 3600 in the create_keychain call to match the shell commands, or remove
the -lut 3600 flags from the later security set-keychain-settings invocations so
the created keychain remains unlocked indefinitely (choose the option that
matches the intended security policy and update both places accordingly).

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

cat -n ios/fastlane/Fastfile | sed -n '60,100p'

Repository: RocketChat/Rocket.Chat.ReactNative

Length of output: 2382

---

Add error suppression to line 68 for consistency with build_official.

The set-key-partition-list command on line 68 should include || true to suppress errors, matching the same command on line 92 in build_official. Both lanes perform identical keychain setup, so they should use consistent error handling.

🤖 Prompt for AI Agents

In ios/fastlane/Fastfile around lines 64 to 68, the `security
set-key-partition-list` command on line 68 lacks error suppression and should
match `build_official` by appending `|| true`; update that sh invocation to add
`|| true` so the command's failure doesn't abort the lane, keeping keychain
setup error handling consistent across lanes.

[github-actions]

iOS Build Available

Rocket.Chat Experimental 4.68.0.107898

[github-actions]

iOS Build Available

Rocket.Chat Experimental 4.68.0.107901