[Firebase AI] Upload xcodebuild logs in integration tests

[andrewheard]

• Added a step in the testapp-integration job of the firebaseai workflow to upload the raw xcodebuild log on failure to help with debugging.
  • Context: xcbeautify filters out a lot of the important details in parameterized Swift Testing-based tests.
  • Split the xcodebuild.log into build and test logs. The test log is a fraction of the size so it's easier to see the test failures when split.
• Followed the xcbeautify guidance for piping the output https://github.com/cpisciotta/xcbeautify#usage.

#no-changelog

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

[gemini-code-assist]

Code Review

Overall, the changes effectively address the need to capture raw xcodebuild logs for debugging integration tests, especially given the limitations of xcbeautify for certain test types. Splitting the build and test steps to get separate logs is a good approach for clarity. The use of NSUnbufferedIO=YES and piping stderr (2>&1) from xcodebuild ensures that the full, unbuffered output is captured by tee and passed to xcbeautify. This is a solid improvement for debugging test failures.

Summary of Findings

• Brittle build action detection: The script assumes the build action (build, test, etc.) is always the last argument passed to RunXcodebuild. This could break if the argument order changes.
• Redundant 2>&1 in pipe: The 2>&1 after tee "$log_filename" is unnecessary as tee's standard output is already piped.
• Split build and test steps: The build test command was correctly split into separate build and test calls to generate distinct logs, as intended by the PR.

Merge Readiness

The changes implement the desired logging behavior and address the issue of xcbeautify filtering. The core logic for capturing logs seems correct. The main point of concern is the potentially brittle method of detecting the build action from the arguments. If the convention of the action always being the last argument is guaranteed within this script's usage, the changes are likely fine. However, if that convention is not strictly enforced, it could lead to incorrect log filenames. I recommend addressing this potential brittleness before merging. Please note that I am unable to directly approve the pull request; other reviewers should review and approve this code before merging.

[paulb777]

Nice! Thanks