-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rare crash on startup in fastlane_folder.rb: in `join': no implicit conversion of nil into String #12789
Comments
@falken42 This is super weird, TBH 😬 The lines is causing confusion is... https://github.com/fastlane/fastlane/blob/master/fastlane/lib/fastlane/cli_tools_distributor.rb#L74 Its not seeing Can you try downgrading to something pre-2.96.0 to see if you do actually stop getting this random error again? 🤔 |
I have the very same issue form some time now... I thought new versions of fastlane will solve it, but so far no luck. I have this issue when I run my builds in CircleCI. As @falken42 has mentioned - it's a random thing, so I cannot determine exactly what's happening and what's causing the problem. Sometimes I have to rerun workflow multiple times, to pass, but sometimes it works on the first run! In my CircleCI's workflow I have two jobs speficied, and this always fails for me when I run the first one. If it completes I'm sure the second job will complete as well! bundle exec fastlane scan I have also two ENV variables set:
|
@joshdholtz I went back and did a deep dive through our buildbot logs, and it turns out this actually has happened with previous versions of fastlane. My original statement that we hadn't seen this before 2.96.0 was incorrect, sorry about that. Log from fastlane-2.85.0: fastlane sigh manage -e -f in dir /Volumes/Buildbot/buildbot-osx/CrystalClash-iOS/build (timeout 1200 secs) watching logfiles {} argv: ['fastlane', 'sigh', 'manage', '-e', '-f'] environment: Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.2j8KZClksG/Render DISPLAY=/private/tmp/com.apple.launchd.rAO2EqRAku/org.macosforge.xquartz:0 EDITOR=vi HOME=/Users/falken LC_CTYPE=UTF-8 LOGNAME=falken PATH=/Users/falken/.fastlane/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin PWD=/Volumes/Buildbot/buildbot-osx/CrystalClash-iOS/build SECURITYSESSIONID=186a8 SHELL=/bin/bash SHLVL=1 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.I7zyoYjKSk/Listeners TERM=xterm-256color TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=400 TERM_SESSION_ID=21E43212-25DB-484D-9BE5-BD234D17C8A1 TMPDIR=/var/folders/_y/bk85gnj92fj_mlk9x1c8nm0w0000gn/T/ USER=falken XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 _=/usr/local/bin/buildbot-worker __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 using PTY: False [19:24:57]: Seems like launching fastlane takes a while - please run [19:24:57]: [19:24:57]: $ [sudo] gem cleanup [19:24:57]: [19:24:57]: to uninstall outdated gems and make fastlane launch faster [19:24:57]: Alternatively it's recommended to start using a Gemfile to lock your dependencies [19:24:57]: To get started with a Gemfile, run [19:24:57]: [19:24:57]: $ bundle init [19:24:57]: $ echo 'gem "fastlane"' >> Gemfile [19:24:57]: $ bundle install [19:24:57]: [19:24:57]: After creating the Gemfile and Gemfile.lock, commit those files into version control [19:24:57]: Get started using a Gemfile for fastlane https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.85.0/fastlane_core/lib/fastlane_core/fastlane_folder.rb:52:in `join': no implicit conversion of nil into String (TypeError) from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.85.0/fastlane_core/lib/fastlane_core/fastlane_folder.rb:52:in `fastfile_path' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.85.0/fastlane/lib/fastlane/cli_tools_distributor.rb:157:in `available_lanes' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.85.0/fastlane/lib/fastlane/cli_tools_distributor.rb:64:in `take_off' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.85.0/bin/fastlane:20:in `' from /Users/falken/.fastlane/bin/bundle/bin/fastlane:22:in `load' from /Users/falken/.fastlane/bin/bundle/bin/fastlane:22:in `' program finished with exit code 1 elapsedTime=5.721645 Two more data points: the very first fastlane version we began using was 2.41.0, and the last version that didn't exhibit this error was with 2.64.1. It might be purely coincidental, but it seems like we started seeing this once fastlane began to suggest we run "gem cleanup". At least, every time fastlane fails, the suggestion to run gem cleanup is always in the log. I've currently updated fastlane to 2.98.0 and haven't seen it repro here yet. It is possible for us to downgrade, but I can't downgrade too far (there are newer deliver and supply features that we depend on to deploy our apps). If there is a specific target version you'd like me to test, let me know and I can see if we can use it. |
We just had this happen with 2.98.0: fastlane sigh manage -e -f in dir /Volumes/Buildbot/buildbot-osx/Sandbox-iOS/build (timeout 1200 secs) watching logfiles {} argv: ['fastlane', 'sigh', 'manage', '-e', '-f'] environment: Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.i0vQVsLZRk/Render DISPLAY=/private/tmp/com.apple.launchd.htpenpkJin/org.macosforge.xquartz:0 EDITOR=vi HOME=/Users/falken LC_CTYPE=UTF-8 LOGNAME=falken PATH=/Users/falken/.fastlane/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin PWD=/Volumes/Buildbot/buildbot-osx/Sandbox-iOS/build SECURITYSESSIONID=186a6 SHELL=/bin/bash SHLVL=1 SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.GtMWyocuk4/Listeners TERM=xterm-256color TERM_PROGRAM=Apple_Terminal TERM_PROGRAM_VERSION=404 TERM_SESSION_ID=21E43212-25DB-484D-9BE5-BD234D17C8A1 TMPDIR=/var/folders/_y/bk85gnj92fj_mlk9x1c8nm0w0000gn/T/ USER=falken XPC_FLAGS=0x0 XPC_SERVICE_NAME=0 _=/usr/local/bin/buildbot-worker __CF_USER_TEXT_ENCODING=0x1F5:0x0:0x0 using PTY: False [02:36:39]: Get started using a Gemfile for fastlane https://docs.fastlane.tools/getting-started/ios/setup/#use-a-gemfile /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.98.0/fastlane_core/lib/fastlane_core/fastlane_folder.rb:49:in `join': no implicit conversion of nil into String (TypeError) from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.98.0/fastlane_core/lib/fastlane_core/fastlane_folder.rb:49:in `fastfile_path' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.98.0/fastlane/lib/fastlane/cli_tools_distributor.rb:167:in `available_lanes' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.98.0/fastlane/lib/fastlane/cli_tools_distributor.rb:74:in `take_off' from /Users/falken/.fastlane/bin/bundle/lib/ruby/gems/2.2.0/gems/fastlane-2.98.0/bin/fastlane:20:in `' from /Users/falken/.fastlane/bin/bundle/bin/fastlane:22:in `load' from /Users/falken/.fastlane/bin/bundle/bin/fastlane:22:in `' program finished with exit code 1 elapsedTime=5.697607 One thing that's different this time though is fastlane isn't suggesting to run "gem cleanup", it just simply failed. |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest |
We've updated to 2.100.1 about a week ago, but I haven't seen a repro yet. |
2.102.0
|
I also ran into this on 2.102.0. It was not an intermittent failure. Uninstalled |
I honestly wasn't expecting to see this happen again. We've moved to GitLab CI (instead of buildbot), and our macOS builder is no longer under the same heavy load as it was when I first posted this report. But yet, our pipeline just randomly failed today:
As usual, retrying the pipeline worked without any problems. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Still happening with fastlane-2.105.2. |
Also repro'd again with fastlane-2.105.2 here as well. It's pretty rare, happening once out of every 70-80 or so builds for us. Retrying the pipeline immediately afterwards is always successful.
I'll update to 2.107.0 now and report back if it happens again. |
Seeing this happen intermittently on multiple recent versions, including 2.107.0. |
For us this is now happening on a daily bases with 2.107.0. |
Another occurence with |
Here someone investigated a bit what is going on: #13586 (comment) |
This comment has been minimized.
This comment has been minimized.
I looked into the code being executed in those threads a bit. There is indeed some code that does |
For documentation: fastlane/fastlane_core/lib/fastlane_core/update_checker/update_checker.rb Lines 125 to 134 in f4849a5
fastlane/fastlane_core/lib/fastlane_core/analytics/app_identifier_guesser.rb Lines 13 to 27 in 3e643b4
if you follow the methods called in here you finally end up at:
This is method that tries to get the Android or iOS package name from the Appfile .
|
Question to everyone here who had this problem: Can you confirm that you have an Update: I could recreate it locally when creating an |
Yes we do have Appfile |
Could it be related to a race condition with |
Yep, that's exactly what I am thinking right now. |
I also have an app file (getting the error every start) |
I don't have an ✅ fastlane environment ✅Stack
System Locale
fastlane files:No Fastfile found No Appfile found fastlane gems
Loaded fastlane plugins:No plugins Loaded Loaded gems
generated on: 2018-12-15 |
Thanks @chnbr. |
Thanks @janpio for the quick answer. The consequence in the case of #13512 is also not that tragic imo since one can continue with Let us know if you need more info. |
@mathaeus I am not sharing your considering #13512 "not that tragic". I currently have a new submission in 18 languages, completely fresh metadata and completely new screenshots. In such a case the html preview is "essential" to review if everything in every language is alright. Sure, you could do the review once it is uploaded in appstoreconnect, but this is very inconvenient, although it does work of course. |
Good news: I think I got it: #13918 I could reproduce the error pretty consistently locally and on Azure Pipelines. Disabling the update made it go away in 100% of the cases, opting out of Analytics did as well. So I looked into the Analytics a bit and discovered that this specific data was not used any more - so I could simply remove the code. #13918 is the PR doing that, and with the next release the problem should be gone. |
@janpio: Great to hear, thanks for the fix! I'd just like to confirm one thing: approximately what version of fastlane started using the analytics code with the offending call to Going back through our fastlane version timeline, we basically saw this:
So if the analytics were added somewhere between 2.64.1 and 2.85.0, it's fairly safe to say that's indeed the problem. |
That code was actually in place since May 2017, which makes this ~2.30.0+. But as it is a race condition, it is basically a timing thing. Any change in the startup process could move the two pieces that clash closer together or further apart. I also think, that the computer/processor being used influences the probability of the race condition being triggered. |
Yeah, that definitely sounds reasonable. Thanks for checking! |
@janpio Thanks for investigating this so deeply! 💯 |
I can confirm we're still able to reproduce without setting FASTLANE_SKIP_UPDATE_CHECK. Will now try with FASTLANE_OPT_OUT_USAGE=1 and let you know. |
Hi! A quick update, I can confirm, setting FASTLANE_OPT_OUT_USAGE=1, we cannot reproduce the error ;) |
No, that was all that I could identify. |
Ahah, I've not tried yet with the latest version as I was not able to update the CI on our side. I was just wondering if you fixed all paths you discovered. If so, we'll update soon and let you know, so we can hopefully close this issue :) |
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest |
This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem 👍 |
New Issue Checklist
Issue Description
We currently run fastlane-2.96.0 on a build server (running buildbot-1.2.0), and occasionally notice a build failure due to one of fastlane's actions failing. The actual action itself seems to be irrelevant (cert, sigh, etc.), however it seems to happen more often when the build server machine is under a heavy load.
Rerunning the build again shortly after the build fails has so far always succeeded, so this is more or less a small annoyance than anything problematic.
We also haven't seen this happen before 2.96.0.
I am aware we aren't using the latest version of fastlane right now, but I decided to submit this report before I forget about it. :) I'll update to 2.98.0 right after this and post a reply here if I see it happen again after the update.
I'll also mention that fastlane suggests I run "gem cleanup" to speed up the launch, but we already do this after every fastlane update. The build machine simultaneously runs multiple compiler processes across multiple VMs, so an occasional slow start is not at all unexpected for our use case.
Complete output when running fastlane, including the stack trace and command used
Environment
🚫 fastlane environment 🚫
Stack
System Locale
fastlane files:
No Fastfile found
fastlane gems
Loaded fastlane plugins:
No plugins Loaded
Loaded gems
generated on: 2018-06-23
The text was updated successfully, but these errors were encountered: