Closed ceeK closed 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!
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.
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.
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.
Awesome! Thank you both. This will save me, and others, a lot of time 🎉
for some reason XCode 14 automatically removes this attribute
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:
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?