Undefined method `gsub' for nil:NilClass

[iby]

Since version 0.2.6 I'm getting this exception with macOS target. It used to happen with 0.2.7 and I remember coming across a similar issue somewhere, apparently it was different. When I revert to 0.2.6, everything works.

/usr/local/opt/gem/gems/fastlane-plugin-versioning-0.2.8/lib/fastlane/plugin/versioning/actions/get_info_plist_path.rb:49:in `find_path_using_target': [!] undefined method `gsub' for nil:NilClass (NoMethodError)
    from /usr/local/opt/gem/gems/fastlane-plugin-versioning-0.2.8/lib/fastlane/plugin/versioning/actions/get_info_plist_path.rb:18:in `run'
    from /usr/local/opt/gem/gems/fastlane-plugin-versioning-0.2.8/lib/fastlane/plugin/versioning/actions/get_build_number_from_plist.rb:8:in `run'
    from /Users/ianbytchek/Development/gifox/build/fastlane/actions/abstract.rb:66:in `get_build'
    from /Users/ianbytchek/Development/gifox/build/fastlane/actions/abstract.rb:74:in `get_version_with_build'
    from /Users/ianbytchek/Development/gifox/build/fastlane/actions/abstract.rb:30:in `get_archive_path'
    from /Users/ianbytchek/Development/gifox/build/fastlane/actions/xcode_archive.rb:14:in `run'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:252:in `block (2 levels) in execute_action'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/actions/actions_helper.rb:50:in `execute_action'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:230:in `block in execute_action'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:226:in `chdir'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:226:in `execute_action'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:148:in `trigger_action_by_name'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/fast_file.rb:146:in `method_missing'
    from lanes/main.rb:5:in `block (2 levels) in parsing_binding'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/lane.rb:33:in `call'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:49:in `block in execute'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:45:in `chdir'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/runner.rb:45:in `execute'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/lane_manager.rb:52:in `cruise_lane'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/command_line_handler.rb:30:in `handle'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/commands_generator.rb:104:in `block (2 levels) in run'
    from /usr/local/opt/gem/gems/commander-fastlane-4.4.5/lib/commander/command.rb:178:in `call'
    from /usr/local/opt/gem/gems/commander-fastlane-4.4.5/lib/commander/command.rb:153:in `run'
    from /usr/local/opt/gem/gems/commander-fastlane-4.4.5/lib/commander/runner.rb:476:in `run_active_command'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane_core/lib/fastlane_core/ui/fastlane_runner.rb:64:in `run!'
    from /usr/local/opt/gem/gems/commander-fastlane-4.4.5/lib/commander/delegates.rb:15:in `run!'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/commands_generator.rb:303:in `run'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/commands_generator.rb:42:in `start'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/fastlane/lib/fastlane/cli_tools_distributor.rb:66:in `take_off'
    from /usr/local/opt/gem/gems/fastlane-2.58.0/bin/fastlane:20:in `<top (required)>'
    from /usr/local/opt/gem/bin/fastlane:22:in `load'
    from /usr/local/opt/gem/bin/fastlane:22:in `<main>'

[SiarheiFedartsou]

@ianbytchek Hi! Thanks for reporting it. It will be great if you share some sample project in which issue is reproduced. Also how do you call get_build_number_from_plist action? Do you use target parameter? If so, just try to substitute it with scheme. And let me know about results.

[iby]

Yes, been using target instead of scheme. Changing to scheme gets this back on track. I used target in first place because was concerned that some schemes have multiple targets.

The issue seems to be with using $(TARGET_NAME) in INFOPLIST_FILE. It works fine with $(inherited) though. Have a feeling this is universal, but if not, try this with CotEditor:

1. Init fastlane and plugin.
2. Replace Fastfile contents with this:

   platform :mac do
     lane :foo do |options|
       version = get_build_number_from_plist(xcodeproj: "CotEditor/CotEditor.xcodeproj", target: 'CotEditor')
       puts version
     end
   end

3. Change CotEditor target INFOPLIST_FILE from CotEditor-Info.plist to $(TARGET_NAME)-Info.plist.

4. Run from project dir: bundle exec fastlane mac foo:

   

5. Restore INFOPLIST_FILE to original value or use scheme instead of target and everything works:

[iby]

@SiarheiFedartsou wondering if this can receive any love? Can I help with anything to make this move forward?

[SiarheiFedartsou]

@ianbytchek Sorry, I cannot promise, but will try to check it at one of the coming weekends.

[SiarheiFedartsou]

@ianbytchek Do you really need to use variables in plist path? And why don't you want to use scheme instead of target? The main issue with target is that we use xcodeproj gem to find INFOPLIST_FILE value and there is no obvious way to force xcodeproj to resolve $()-shape variables. At least I didn't find it :( We can resolve it at our side, but I think we can only support restricted subset of such variables.

[iby]

Do you really need to use variables in plist path?

Yes, I have more than a few projects using this with default config based on xcconfigs – it's consistent, logical and organised, I'm happy with it.

And why don't you want to use scheme instead of target?

That's what I do as a workaround and it works. I've originally built all fastlane scripts around target parameter – most importantly it is very explicit, but also scheme for target may not exists, scheme can build multiple targets, etc. Theoretically speaking, there might be situations, where it's not going to work, in practice, I don't imagine a lot of such cases. Not with my workflow anyway.

The main issue with target is that we use xcodeproj gem to find INFOPLIST_FILE value and there is no obvious way to force xcodeproj to resolve $()-shape variables. At least I didn't find it :( We can resolve it at our side, but I think we can only support restricted subset of such variables.

I remember looking into this back September, yes, issue was somewhere deeper, but I was under impression that xcproject does resolve them, after all, it works with scheme and I believe I found actual evidence, but not gonna claim on this. If it doesn't, then this definitely shouldn't be fixed in this repo and the issue should be closed. Thanks for looking into this! 🤜🤛