Gradle hangs in Xcode pre-build actions

[alistra]

Even very simple Gradle configuration hangs when being run from Xcode pre-build action running through xcodebuild.
Bug was initially reported to Apple (response in the screenshots attached) but they identified it is an issue with Gradle.
This happens even with gradle tasks so it is independent of the configuration of the build process.

Expected Behavior

When gradle is run to build something from an Xcode pre-build action step, it should finish normally, like it does when invoked from the terminal directly.

Current Behavior

The gradle process hangs and the xcodebuild does not finish.

Context

I'm trying to build a Kotlin-Multi-Platform artifact to use in my iOS app as a pre-build action step in Xcode.

Steps to Reproduce

• attached a zip Xcode project with gradle invocation in the pre-build action step
• notice that when running directly from Xcode (with GUI) the gradle invocation finishes with success
• notice that when running using xcodebuild archive command line utility

Your Environment

❯ ./gradlew -v

------------------------------------------------------------
Gradle 6.7
------------------------------------------------------------

Build time:   2020-10-14 16:13:12 UTC
Revision:     312ba9e0f4f8a02d01854d1ed743b79ed996dfd3

Kotlin:       1.3.72
Groovy:       2.5.12
Ant:          Apache Ant(TM) version 1.10.8 compiled on May 10 2020
JVM:          1.8.0_201 (Oracle Corporation 25.201-b09)
OS:           Mac OS X 10.15.7 x86_64

❯ xcodebuild -version
Xcode 12.3
Build version 12C33

GradlePreActionTest.zip

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[stale]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to to let know so we can reopen the issue. Please try to provide steps to reproduce, a quick explanation of your use case or a high-quality pull request.

[alistra]

Please reopen

[alistra]

I hate it that noone answered in the ticket and the ticket is closed due to inactivity.

[eskatos]

Sorry about that @alistra. I'm reopening the issue.
Do you confirm you can still reproduce this problem?

[alistra]

Yes both on newest stable Xcode 13 & Xcode 14 beta

[MartinStrambach]

I can also confirm it's still an issue and it's really an annoying one.

[eskatos]

Could one of you provide the Gradle daemon logs at the time of the hang?
Daemon logs can be found in ~/.gradle/daemon/<gradle-version>.

[alistra]

daemon-98888.out.log

I don't know which part of the log is relevant tbh

[MartinStrambach]

Here's mine: daemon-22105.out.log

[eskatos]

Thank you both.
I did not find anything helpful in the logs. They both show build finishing successfully and normal daemon behavior.

@lacasseio, does it ring a bell?

[lacasseio]

I think I remember seeing something similar to that and if I remember correctly it has to do with the daemon. Try using --no-daemon and report back.

From what I remember, Xcode wants to wait for all process started to exit. In some scenario, the execution reuse a daemon which is ignored by Xcode and does not hang. However, in other scenario a new daemon may be spawn causing Xcode to wait (hang).

[alistra]

I believe at the time I was trying --no-daemon and it didn't help either.

I am available for a playdate if you need to debug this on a machine with Xcode setup.

[lacasseio]

I digged a bit further and found your issue when comparing to Nokee's run script for Xcode. You have to nullify the inputs, so your command has to be ./gradlew tasks < /dev/null. If I remember correctly, Gradle reads some inputs as soon as it starts. For some reason, Xcode must pipe the input stream in a way that cause Gradle to "expect" something (or vice-versa).

[alistra]

@lacasseio this in fact fixes the issue and works around the problem. Do you have any idea why this might be? Is this an Xcode issue, or just Gradle waits for input if it autodetects some condition from the environment and maybe this logic is buggy?

[lacasseio]

Unfortunately, I didn't dig too deeply into the issue. My guess was probably having to do with how Gradle reads from the stdin and how Xcode provides the stdin to the script. I'm not aware Xcode allows inputs to be passed to run scripts. I would assume that Xcode may simply use a closed stdin (or something strange for the non-Apple world) by default which Gradle may not support (or fall into a hanging code path). Looking at the daemon logs, the daemon starts up but doesn't receive the build command, so it seems like the daemon startup procedure is at fault. Gradle swap the System.in with its own so it can process user inputs (as part of an internal API). This process is split into two parts, the wrapper will receive the data and pass it to the daemon via its wrapper/daemon socket.

That is, unfortunately, as far as I can go with my diagnostic. Gradle codebase can be confusing to follow, so I couldn't find the exact code path that processes the input. I know I found it in the past as there was a bug that dropped inputs as it was reading everything available on each input process which would break things like gradle init < all-init-answers.txt (for unattended initialization).

As you mentioned, there is a bug here or an unintended side-effect. Gradle should either not hang or crash with a good error message. My general rule of thumb when writing defensive shell scripts is to null the inputs of commands I don't expect any user input processing as it better demonstrates the intent. I hope that help.

[alistra]

The hint is also that it doesn't hang when you trigger the action through a button in the Xcode GUI, but it hangs when you invoke a CLI command.

I'm not an expert, but similar issues when when trying to run keychain commands on a macOS Jenkins node and depending if the Jenkins was running as a LaunchAgent or a LaunchDaemon it was behaving differently and had different permissions? Maybe this is somehow related, that gradle is hanging on some kind of resource that is accessible when you invoke the action from GUI, but not accessible if you go through a command line command - just guessing.

[azarovalex]

The problem still exists in Xcode 15.1, everything works as expected in Xcode GUI, but running xcodebuild from CLI puts gradle in some kind of enless loop. This happens only if gradle is called as part of pre-build scheme action.
Fortunately ./gradlew tasks < /dev/null hack works, thanks @lacasseio.