Fastlane scan fails: unable to open dependencies

#1

Bitrise Build Issue Report template

Description of the issue

Fastlane scan fails on the 10.2 Mojave stack due to that it can’t open dependencies file. I’ve changed the simulator to iPhone 5s (12.2).
It runs fine on the former stack, completes all the steps. However, it doesn’t on the new one.

Error log:

[10:57:31]: ▸ :x: error: unable to open dependencies file (/Users/vagrant/Library/Developer/Xcode/DerivedData/********/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/Toast-Swift.build/Objects-normal-tsan/x86_64/Toast.d)Command CompileSwiftSources emitted errors but did not return a nonzero exit code to indicate failure

Environment:

Where did the issue happen?

Stack Xcode 10.2 on MacOS 10.14 (Mojave)

Which build Step causes the issue and which version of the step?

Fastlane (latest) (2.4.0)

Reproducibility

  • _Does a “Rebuild” help?: NO
  • _Does a rebuild without caches help?: NO
  • Does the issue happen sporadically, or every time? : Every time
  • Does upgrading the build Step to the latest version help? : NO (already latest)
  • When did the issue start? : Yesterday, 27th of march

Local reproduction

_Can it be reproduced on your own Mac/PC by following our local debug guide? NO (after modifying my bitrise.yml, removing the fastlane step and adding instead a manual bundle exec fastlane ci in shell step). Tests run using fastlane’s scan.

Build log

Lastest failed build (where I also removed the fastlane step): https://app.bitrise.io/build/9a90c3576c0063dc

Error:

error: unable to open dependencies file (/Users/vagrant/Library/Developer/Xcode/DerivedData/****/Build/Intermediates.noindex/Pods.build/Debug-iphonesimulator/Toast-Swift.build/Objects-normal/x86_64/Toast.d)Command CompileSwiftSources emitted errors but did not return a nonzero exit code to indicate failure
0 Likes

#2

Hy there,

could it be that this is the real issue: Underlying error: Failed to install the requested application. The bundle identifier of the application could not be determined. ?

0 Likes

#3

Hi!
No, that is not the or an issue. The bundle identifier is present. After a lot of tinkering and trying I got it yesterday to work by setting the -UseNewBuildSystem=NO flag in my fastfile. However, I have since removed it and all works. Right now I can’t really see what the issue was but nevertheless it is working.

0 Likes