Add Fastlane

[jonathajones]

Reason for changes

We can use Fastlane to

1. Run tests locally and (potentially) via Github Actions
2. Release the SDK via each of our dependency managers as part of our CI process
3. Attach code coverage test reports / code coverage reports to PRs (in conjunction with GH actions)

These are all things that can be done via a rakefile or exclusively through GH actions, but using fastlane means we can take advantage of the built in fastlane actions (https://docs.fastlane.tools/actions/), as well as have flexibility to run lanes from the command line instead of relying exclusively on GH actions to not fail.

In order to run fastlane via CI, we would just need to run bundle exec fastlane tests

Summary of changes

• Added a Gemfile and a Fastfile
• Added a single lane to execute our unit tests
• Edited the test scheme to be able to run all of our test targets (this was causing the test command to fail)

[scannillo]

The fastlane command for me with Path '/Applications/Xcode-13.0.app' doesn't exist since my Xcode 13 beta is called Xcode-beta.app. Using xcode-select --print-path I can confirm it is pointing properly to my Xcode, but for some reason the Fastlane command is still failing.

The tests pass for me fine when running the actual xcodebuild command: xcodebuild -workspace 'PayPal.xcworkspace' -sdk 'iphonesimulator' -configuration 'Debug' -scheme 'UnitTests' -destination 'name=iPhone 11,platform=iOS Simulator' test.

I assume Fastlane needs everyone to have their Xcode 13 beta in the same name/location?

[jonathajones]

The fastlane command for me with Path '/Applications/Xcode-13.0.app' doesn't exist since my Xcode 13 beta is called Xcode-beta.app. Using xcode-select --print-path I can confirm it is pointing properly to my Xcode, but for some reason the Fastlane command is still failing.

The tests pass for me fine when running the actual xcodebuild command: xcodebuild -workspace 'PayPal.xcworkspace' -sdk 'iphonesimulator' -configuration 'Debug' -scheme 'UnitTests' -destination 'name=iPhone 11,platform=iOS Simulator' test.

I assume Fastlane needs everyone to have their Xcode 13 beta in the same name/location?

In order to run the lane locally as it's currently written - yeah it would need to be in the same place. But i was looking at the other github actions in the current open PR - we could make the xcode-select command part of the github action, without having it as part of fastlane. That would enable us to run our lanes locally without worrying about Xcode naming and location. What do you think about this ?

[scannillo]

In order to run the lane locally as it's currently written - yeah it would need to be in the same place. But i was looking at the other github actions in the current open PR - we could make the xcode-select command part of the github action, without having it as part of fastlane. That would enable us to run our lanes locally without worrying about Xcode naming and location. What do you think about this ?

I'm a little confused. How would updating the xcode-select part of the GH Actions workflow help our local test running?

Also, I think we could remove xcode_select() from the Fastfile and that would just use whatever the user's default XCode tooling setup is.

[jonathajones]

I'm a little confused. How would updating the xcode-select part of the GH Actions workflow help our local test running?

Also, I think we could remove xcode_select() from the Fastfile and that would just use whatever the user's default XCode tooling setup is.

In the GH action flow, we could run xcode-select to ensure the right xcode has been selected before we start using any of our fastlane actions.

For example:

name: Tests
on: [pull_request, workflow_dispatch]
jobs:
  unit_test_job:
    name: Unit
    runs-on: macOS-11
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2
      - name: Use Xcode 13
        run: sudo xcode-select -switch /Applications/Xcode_13.0.app
      - name: Run Unit Tests
        run: bundle exec fastlane tests

If we want to use fastlane locally, it would be up to us to make sure the correct xcode has already been selected - hopefully this makes more sense.

[scannillo]

If we want to use fastlane locally, it would be up to us to make sure the correct xcode has already been selected - hopefully this makes more sense.

I see - you're saying to use Fastlane in CI as a way to test that Fastlane will work locally if you were to follow that same Xcode setup.

I vote for removing the xcode_select() command from the Fastfile instead. This will respect the Xcode preferences set on the user's machine instead, which actually might be useful in some cases (ex: testing old/new xcode versions locally or new minor versions).

[jonathajones]

I vote for removing the xcode_select() command from the Fastfile instead. This will respect the Xcode preferences set on the user's machine instead, which actually might be useful in some cases (ex: testing old/new xcode versions locally or new minor versions).

Ah i think we're thinking the same thing - I removed the xcode_select action here

[scannillo]

Another general question - I know we talked about wanting to get parity in our test scripts across Android & iOS. We might want some Android 👀 on this as well - Is Fastlane a good option for Android as well?

Also, I'm thinking ... using the xcodebuild commands directly could be simpler. It gives us transparency and allows us to know exactly what command is being run and doesn't require additional setup. Thoughts?

I know you mentioned that we can use Fastlane to Release the SDK via each of our dependency managers as part of our CI process. To publish to SPM, we just push a tag to the repo, and to publish to CocoaPods it's just pod trunk push. I'm not sure I understand the benefit to using Fastlane for this. Is there something I am missing that Fastlane does to signifigantly improve this process?

[jonathajones]

Another general question - I know we talked about wanting to get parity in our test scripts across Android & iOS. We might want some Android 👀 on this as well - Is Fastlane a good option for Android as well?

Fastlane can be used on Android as well - can't vouch for it personally though!

Also, I'm thinking ... using the xcodebuild commands directly could be simpler. It gives us transparency and allows us to know exactly what command is being run and doesn't require additional setup. Thoughts?

I definitely understand wanting to have more control / visibility into the command being executed. Benefit of having the command abstracted (even if we just call a bash xcodebuild command to run the test suite from a lane), is that it's easier to remember fastlane test or fastlane code_coverage than the equivalent build commands. But that doesn't require fastlane specifically (and also maybe the ability to invoke everything easily from the command line isn't that big of a deal?)

I know you mentioned that we can use Fastlane to Release the SDK via each of our dependency managers as part of our CI process. To publish to SPM, we just push a tag to the repo, and to publish to CocoaPods it's just pod trunk push. I'm not sure I understand the benefit to using Fastlane for this. Is there something I am missing that Fastlane does to signifigantly improve this process?

the benefit of using fastlane just to wrap pushing our podspec is pretty minimal. fastlane could be beneficial if we decide to in the future take better advantage of other baked in fastlane actions (code coverage / doc gen).

Maybe we can talk this week about whether or not we want to actually go this route, or if relying on github actions is sufficient for us right now

[sarahkoop]

Maybe we can talk this week about whether or not we want to actually go this route, or if relying on github actions is sufficient for us right now

From the Android side - I see that Fastlane is compatible but have never used it personally. Without knowing too much about the benefits it offers for Android, I also think there may be a lighter-weight solution like a bash script that would allow us to have parity in commands across repos without pulling in another tool. I'd second having a group conversation about the route we want to go for both iOS and Android.

[scannillo]

the benefit of using fastlane just to wrap pushing our podspec is pretty minimal. fastlane could be beneficial if we decide to in the future take better advantage of other baked in fastlane actions (code coverage / doc gen).

Gotcha, this makes sense! Also, it would be rad if we could automate builds to TestFlight at some point for our demo (I think we can super punt 🏈 on this though for now). I know that TestFlight doesn't always 100% match the App Store review process, but it can still be helpful and offer warnings/rejections. We've gotten burned in the past by not catching an App Store review issue until merchants reported it.

I think Fastlane could be a good tool for something like this too.

[scannillo]

I think after your recent changes, this whole file can be reverted back now

[scannillo]

After running this locally these files are generated:

Untracked files:
  (use "git add <file>..." to include in what will be committed)
	fastlane/report.xml
	fastlane/test_output/

Should we put these in the gitignore?

[jonathajones]

Added the report.xml to the git ignore file. the test_output folder should not be generated anymore - try removing the directory and running the tests again? That was a directory that was previously output by run_tests, which is no longer included in this PR.

[scannillo]

🚀

[minhthenguyen]

I have one minor comment/question, otherwise this looks good to me!!!! 😄