Deprecating Fastlane

[LetoFranco]

Description:

• Removing Fastlane from code

Motivation

The motivation behind this change is to have a code base from which we can decide and add our decisions in each project on top of the base, without having to double check after using the script to see what we should have and what we should delete.

For example:
I think it's preferable not to have commented decisions in the readme, because it's similar to having commented code.

---

Alternative 1

Generate an issue in Github to create a notion page to store how to install and integrate Fastlane to a project.

Generate another issue to find a way to store the fastlane configuration file in some project to show how it is integrated.

---

Alternative 2

Another solution, could be to modify the script to add a check to ask if you want to keep fastlane or bitrise or leave it custom.

In case you decide to go for fastlane, see if it is installed or install it, and if not, remove the fastlane traces.

[glm4]

@LetoFranco what's the motivation for this change?
The last think I know is that we want the ios-base to be an example of how to configure our CI/CD workflows with Fastlane.

[LetoFranco]

@LetoFranco what's the motivation for this change? The last think I know is that we want the ios-base to be an example of how to configure our CI/CD workflows with Fastlane.

Hey @glm4, i added more details to the description in order to give more visibility about the motivations of the change.

[glm4]

@LetoFranco what's the motivation for this change? The last think I know is that we want the ios-base to be an example of how to configure our CI/CD workflows with Fastlane.

Hey @glm4, i added more details to the description in order to give more visibility about the motivations of the change.

I think we should discuss this on the next iOS Roundtable as a team, and take a better look at the possible advantages and disadvantages.

[glm4]

@LetoFranco Can you make sure all the following works for the repo after removing Fastlane?

The only thing we would need to change is to run the test suite from the Github actions by using xcodebuild ... test rather than the fastlane run_test_suite lane.
If we decide NOT TO go with the Fastlane approach because it introduces complexity to the workflow, the minimum requirements I considere this repository should met are:
The test suite must run for each PR and changes to master
The code coverage report to Code Climate must continue working.

[glm4]

@LetoFranco why is this file deleted?