fastlane: update_app_identifier and update_project_provisioning both change current directory, but do not change back when done

New Issue Checklist

Updated fastlane to the latest version
I have read the Contribution Guidelines

Issue Description

If you run the update_app_identifier or the update_project_provisioning action, they change directories from ${SRCROOT}/fastlane to ${SRCROOT}, but they never change back when they are done. This causes other code that looks for files in a specific path to always fail to find the file, and fastlane fails at that point. We run fastlane on multiple apps at once in a loop, so we’re running these actions multiple times per lane execution. This only started happening recently, somewhere between fastlane 1.101 and 1.104.

Complete output when running fastlane, including the stack trace and command used

Prefer not to include, as it's sensitive. See example lane instead that reproduces issue

Configuration Files

Please copy the complete content of your Fastfile and any other configuration files you use below:

Fastfile:

  # lane that reproduces issue:
  lane :bug do
      puts File.absolute_path(".")
      # first time it's ${SRCROOT}/fastlane, second time it's ${SRCROOT}.
      # It should always be one or the other (preferrably the first as that's how it worked before).

      # replace with your own project info
      proj = 'WayfairApp.xcodeproj'
      plist = 'WayfairApp/Info.plist'
      identifier = 'com.wayfair.WayfairApp'
      target_pattern = '^WayfairApp$'

      # problem action 1
      update_app_identifier(xcodeproj: proj,
                            plist_path: plist,
                            app_identifier: identifier)
      # problem action 2
      cert
      sigh(app_identifier: identifier)
      update_project_provisioning(xcodeproj: proj,
                                  target_filter: target_pattern)

      puts File.absolute_path(".")
  end

Environment

fastlane version (run fastlane -v): fastlane 1.104.0

Do you use bundler to execute fastlane (i.e. bundle exec fastlane)? no

Do you use a Ruby environment manager (e.g. chruby, rbenv, rvm)? rbenv, but happens on machines without it

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 20 (3 by maintainers)

Most upvoted comments

great, thank you for the update and the related bug @mfurtak! This works for me and solves the original bug that I encountered.

klundberg on Oct 17, 2016

Note: I also tested by removing the update_app_identifier and the gym started to compile the project.

quenbob on Oct 14, 2016

with fastlane 1.105 this seems to be worse. now in my fastfile, if i first call update_app_identifier and then call update_project_team (while providing a path to the project for each), the second one fails since it can’t find the project at a relative path name. for example:

update_app_identifier(xcodeproj: "myproj.xcodeproj", 
  plist_path: "myproj/Info.plist",
  app_identifier: "com.example.myproj")

# fails here since it can't find myproj.xcodeproj wherever it happens to be looking.
update_project_team(path: "myproj.xcodeproj", 
  teamid: "12345")

I’ve tried various tricks like getting absolute paths stored in ENV in a before_all block, but that doesn’t seem to work in update_app_identifier (i presume that action is always looking at the current directory, not resolving absolute paths properly)

EDIT: If I pin my gemfile to Xcodeproj 1.3.1, this new issue is resolved. Haven’t yet tried other xcodeproj versions to see if those fix anything else.

klundberg on Oct 10, 2016