MobileNativeFoundation / XCLogParser

Tool to parse Xcode and xcodebuild logs stored in the xcactivitylog format
Apache License 2.0
1.72k stars 121 forks source link

Question around placing the script in a scheme's post-action #77

Closed ceeK closed 4 years ago

ceeK commented 4 years ago

Hey all,

Firstly thank you for this tool, it's absolutely fantastic and is a massive help to my use case: tracking build times on DataDog.

This statement exists in the readme around placing the script within a scheme's post-action that I think might be slightly ambiguous:

In this way, the last build log can be parsed as soon as a build finishes...

I interpreted this to mean that when you build the scheme, the xcactivitylog for that build is parsed at the end of the build. However upon further investigation it looks as though the xcactivitylog is only created after the post-build script is ran, which means that it's always reporting on the current_build - 1.

This is a problem in my case as the last build could have been yesterday, and DataDog requires timestamps on any metrics to be "defined as not more than 10 minutes in the future or more than 1 hour in the past".

I managed to get around this by offloading the running of the script to the background and waiting for a second or so. This allows Xcode to generate the xcactivitylog for the current build, before it is parsed (and then sent to DataDog in my case).

If this is not a misunderstanding by me, or problem on how I've set this all up, it might be worth highlighting this in the readme?

BalestraPatrick commented 4 years ago

Yes, we encountered this issue as well. Xcode waits for the command ran in the post-build script to finish before even showing the "Build Succeeded" message for example. We got around this problem by offloading the actual invocation to an external script that we call "launcher":

#!/bin/sh

# The first argument is the directory of the executable you want to run.
# The following arguments are directly forwarded to the executable.
# We execute the command in the background and immediately close the input, output
# and error streams in order to let Xcode and xcodebuild finish cleanly.
# This is done to prevent Xcode and xcodebuild being stuck in waiting for all 
# subprocesses to end before exiting.
executable=$1
shift;
$executable "$@" <&- >&- 2>&- &

The actual post-scheme in Xcode then becomes: Launcher YourCommandToUploadToDataDog

We'll look into adding this to the README for all future readers. Thanks a lot!

ceeK commented 4 years ago

Thanks a lot @BalestraPatrick!

Whilst I have you, I'm wondering whether you have experience on reporting failed builds as well as successful, given that the post-action script only runs for successful builds? I'm looking into this on my end so if you have any tips here, that'd be fantastic.

polac24 commented 4 years ago

Hi @ceeK! Glad you asked, we have a workaround for that too. There is an undocumented, unofficial runPostActionsOnFailure attribute for the scheme action defined in *.xcscheme file. You have to manually add it to the BuildAction like:

<BuildAction buildImplicitDependencies='YES' parallelizeBuildables='YES' runPostActionsOnFailure='YES'>

That triggers an action also for a build failure but still not for a manually stopped build.

BalestraPatrick commented 4 years ago

Yes, that's the undocumented feature we use to execute the action even on failure. I'll prepare a PR to add these "tips & tricks" to the README.

ceeK commented 4 years ago

Awesome! Thank you both. This will save me, and others, a lot of time 🎉

yasirmturk commented 1 year ago

for some reason XCode 14 automatically removes this attribute Screenshot 2022-11-08 at 10 55 55