DEVELOPER_DIR is not set for usage with fastlane

Recently we have had some issues when using this action with fastlane, that our lanes have still been using wrong versions of Xcode, even after version is being set.

Fastlane itself recommends either to use xcode-select (which this action does) or set DEVELOPER_DIR. https://docs.fastlane.tools/actions/gym/#usage

Currently we are solving it in a bit hackish way and use MD_APPLE_SDK_ROOT set for Xamarin.

    steps:
      - uses: maxim-lobanov/setup-xcode@v1
        with:
          xcode-version: 11.7

      - name: Build Simulator build
        timeout-minutes: 15
        env:
          # N.B. Unless we set this, fastlane will still use default Xcode available on the machine
          DEVELOPER_DIR: ${{ env.MD_APPLE_SDK_ROOT }}
        run: |
          bundle exec fastlane ios build_simulator 

Considering that xcode-select is actually used, alternative version woudl be to use:

DEVELOPER_DIR: $(xcode-select --print-path)

But I was wondering, considering how often fastlane used for iOS, would you consider adding this or accepting the PR, which sets DEVELOPER_DIR as a part of workflow? Or should we consider some other solutin?

Thanks in advance.

[maxim-lobanov]

@dentuzhik, that sounds really interesting. See output of xcode-select --print-path in step Log Xcode settings. It is not equal to path on clean image. If you run xcode-select --print-path as a first step of the build (clean image), it will show /Applications/Xcode_12.app/Contents/Developer.

So, some step between setup-xcode and Log Xcode settings invokes xcode-select -s "/Applications/Xcode.app and change Xcode. I think steps Install brew dependencies or Installing dependencies can switch Xcode somehow. I have already seen examples where brew install builds something from source code and use Xcode for that. Could you please try to move setup-xcode step lower in YAML iteratively and check build logs?

Also could you please expand env section for step Log Xcode settings on the first screen? Does it contain something interesting?

[dentuzhik]

We figured out what was wrong. The problem was that we specified iphonesimulator SDK when creating the build, which apparently assumed latest version of SDK available on the system.

Because we had two versions of Xcode, 11.7 and 12.3, latest SDK always referred to latest Xcode installation effectively ignoring what we have provided via xcode-select. As soon as I switched build to iphonesimulator13.7 our issues with Xcode went away.

Let me know if it makes sense (or maybe my theory is incorrect), and I assume we can close this.