Carthage Concurrent Build Fail.

[zorture]

• carthage version: 0.20.1 & 0.24.0
• xcodebuild -version: 8.3.2
• Are you using --no-build No
• Are you using --no-use-binaries No
• Are you using --use-submodules No
• Are you using --cache-builds No

* Instructions *
I am running carthage update --platform ios from Folder A and B simultaneously. The command which has been triggered first fails.
Conclusion carthage update fails for concurrent update.

Cartfile

A.zip
B.zip

Carthage Output

* Error Log *

* Requirement *
I make 4 - 5 builds daily with different carthage tags. Since simultaneous build fails, i am not able to completely automate the CI.

* Issue Root Cause *
I noticed the root cause of the issue is the shared cache.

Is there any way to have a private cache for carthage update so i can achieve concurrency?

[ikesyo]

I don't think this is an expected usage of Carthage.

Anyway, could you please check https://github.com/Carthage/Carthage/pull/2112#issuecomment-322286205.

You can specify a custom derived data if you'd like to do that. carthage bootstrap --derived-data <path to the custom derived data folder>

Note that you probably want to run carthage bootstrap on CI, not carthage update.

[mdiep]

This should work (but apparently isn't) if you pass a custom derived-data directory for each.

[bwhiteley]

--derived-data is insufficient because the shared cache contention often occurs under ~/Library/Caches/org.carthage.CarthageKit/dependencies (git .lock files, for example).

[tmspzz]

@bwhiteley are you experiencing this problem? https://docs.microsoft.com/en-us/vsts/git/git-index-lock ?

Or can you provide sample Cartfiles? Can you add the error output?

Edit: Relates to: https://github.com/Carthage/Carthage/issues/1187

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bitbytedog]

This issue is still present in carthage 0.31.1. It causes a problem for our CI system which builds the iOS architectures in parallel - sometimes two parallel jobs are scheduled on the same machine. The failure rate is very high with the following message:

~~~~
* Checking out CocoaLumberjack at "3.4.2"
A shell task (/usr/bin/env git checkout --quiet --force 0.7.1 (launched in /Users/*/Library/Caches/org.carthage.CarthageKit/dependencies/PopupDialog)) failed with exit code 128:
fatal: Unable to create '/Users/*/Library/Caches/org.carthage.CarthageKit/dependencies/PopupDialog/index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
~~~~

The actual failure point is random, depending on timing.

A workaround was to ensure that only one instance of carthage ran at any time in the sections of the build process that were being parallelised. For example, xcodeproj run scripts were updated to include a spin lock:

~~
while ! mkdir $TMPDIR/carthage.lock 2> /dev/null ; do
kill -0 $(cat $TMPDIR/carthage.lock/owner) && sleep 1 || rm -rf $TMPDIR/carthage.lock
done
echo $$ > $TMPDIR/carthage.lock/owner
trap 'rm -rf $TMPDIR/carthage.lock' EXIT INT TERM
carthage bootstrap --platform iOS --cache-builds
~~

[GabKlein]

This issue could be solved by simply offering an option to change the userCachesURL value (~/Library/Caches/org.carthage.CarthageKit/) dynamically using an environment variable to (in my case) the current path of the project (uniq per instance of CI jobs). How can we move forward with it?

[kenji21]

I don't think this will solve it, because this MR cache the built framework, and the git commands are executed before this (in dependencies):

ls ~/Library/Caches/org.carthage.CarthageKit/
DerivedData  SharedCache  binaries     dependencies

[JWShroyer]

@mdiep I noticed you requested this issue be opened from #2112 to discuss further for a solution, but I see this issue is closed. Did you folks get anywhere with this issue?

Last I checked I was having a similar problem with my team using version 0.35, but after reading through these threads a bit I'm wondering if that's a difference between the update and bootstrap commands. My issue could be one of a few I've read, so I'll need to go back through and see what it is specifically, but from reading it sounds like it could be:

1. A difference between the update command not supporting parallelization and bootstrap maybe working.
2. A contention with a .lock file as described in #1187 and linked by @tmspzz

I'll take a look at this either later today or the day after and report back my specifics with this issue.

---

Update

It looks like the problem I have is in regards to the .lock as this is my output:

A shell task (/usr/bin/env git checkout --quiet --force 99a1984bea389a07814831cee95957087c9fb5c1 (launched in /Users/{username}/Library/Caches/org.carthage.CarthageKit/dependencies/{private-dependency})) failed with exit code 128:
fatal: Unable to create '/Users/{username}/Library/Caches/org.carthage.CarthageKit/dependencies/{private-dependency}/./index.lock': File exists.

Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.

[zorture]

My solution worked for Me.
It's an Update command.
carthage update --platform ios --private-cache

On specifying --private-cache , all the build will have it's own private cache and Carthage worn't fail the build due to file lock.
https://github.com/zorture/Carthage/tree/Carthage_Private_Cache

[JWShroyer]

Thanks, @zorture! Are there plans to integrate your work back into the main Carthage project here?

[zorture]

PR was rejected. "Not expected usage of Carthage".
https://github.com/Carthage/Carthage/pull/2112

Please Note: My entire solution was around CI (Jenkins) Builds only.
Another solution we used is to upload the binary back into git and use Carthage to download the binary. This save a lot of build time.

[codeslubber]

Jesus I am going to throw a party when we can finally stake Carthage. In a world where most build tools suck, Carthage is pretty special. We cannot promote a release because of this concurrency constipation. Thanks.

[jdhealy]

@codeslubber, people work on this project… that tone is unacceptable.

If there was, say, a bike path in your community that people worked on — would you express qualms you had in the same way?

To people that spend their free time doing what they can?

[codeslubber]

and there's the classic OS argument: sure we completely mucked up your life but because we are doing it out of the goodness of our hearts, we won't tolerate one ounce of disdain... thanks @jdhealy, and saying a tool that doesn't even work anymore sucks is pretty mild...

[jdhealy]

sure we completely mucked up your life

there might be some misplaced anger here…

…much love, @codeslubber

[codeslubber]

@jdhealy 3 days to make a build that took a few minutes a hundred times, but yeah you are right dimestore psych it away, in reality I had to get a release out before the end of the month and wasted way too much time on it, but it's done now... hey I blame Apple most: if I were working on Carthage SPM would have demotivated me, but of course, it's still not fully usable so we are trapped in the door... thanks to anyone who patched the Xcode 12 mess...