Streamline and update `Rakefile`

[mokagio]

While working on #18845 and #18850, I noticed a few things that could be improved in the Rakefile:

• DRY how we load Podfile.lock
• We have tasks such as test and clean that are redundant given our use of Fastlane. We should either remove them or make them run the appropriate Faslane lane under the hood.

WordPress-iOS/Rakefile

Lines 216 to 224 in 2185a1e

	desc 'Run test suite'
	task test: [:dependencies] do
	xcodebuild(:build, :test)
	end
	desc 'Remove any temporary products'
	task :clean do
	xcodebuild(:clean)
	end

• Same goes for this custom xcodebuild call. Fastlane can do this for us with extra parameter and safety checks.

WordPress-iOS/Rakefile

Lines 732 to 743 in 2185a1e

	def xcodebuild(*build_cmds)
	cmd = 'xcodebuild'
	cmd += " -destination 'platform=iOS Simulator,name=iPhone 6s'"
	cmd += ' -sdk iphonesimulator'
	cmd += " -workspace #{XCODE_WORKSPACE}"
	cmd += " -scheme #{XCODE_SCHEME}"
	cmd += " -configuration #{xcode_configuration}"
	cmd += ' '
	cmd += build_cmds.map(&:to_s).join(' ')
	cmd += ' | bundle exec xcpretty -f `bundle exec xcpretty-travis-formatter` && exit ${PIPESTATUS[0]}' unless ENV['verbose']
	sh(cmd)
	end

Also note that xcodebuild call will likely fail, because "iPhone 6s" is no longer one of the Simulator that ship with Xcode out of the box:

[peril-wordpress-mobile]

	Fails
🚫	Please add a type label to this issue. e.g. '[Type] Enhancement'

Generated by 🚫 dangerJS

[mokagio]

@jkmassel @crazytonyli @kean @dcalhoun in the context of removing Ruby from the day-to-day dev toolchain, what do you think of either:

• Ditch Rakefile
• Convert the set up tasks to Makefile

How much weight do you put into keeping the apps OSS-contributor friendly? Depending on that, we might be able to remove a lot of code or will need to convert it, too.

[dcalhoun]

I don't have any particular stance against pursuing DRY or removing duplicative tasks.

How much weight do you put into keeping the apps OSS-contributor friendly? Depending on that, we might be able to remove a lot of code or will need to convert it, too.

It is unclear to me how the presence of a Rakefile (vs Makefile) relates to OSS-contributor friendliness. Are you positing one is more approachable than the other? Presumably, either file could be approachable provided we sufficiently document how to use it—e.g., basic examples in the README or elsewhere.

[mokagio]

Thanks @dcalhoun

Regarding OSS-contributor friendliness, I am referring to part of the automation dedicated to setting up the environment explicitly for devs who are not part of Automattic and therefore do not have access to things like mobile-secrets.

Example:

WordPress-iOS/Rakefile

Lines 283 to 291 in 7f0b34d

	desc 'Install and configure WordPress iOS and its dependencies - External Contributors'
	namespace :init do
	task oss: %w[
	install:xcode:check
	dependencies
	install:tools:check_oss
	install:lint:check
	credentials:setup
	]

Porting those tasks (and committing to seriously maintaining them) would be additional work. Work that I'm sure we'd all be happy to do if there's a compelling reason to keep the app easy to set up for external contributors.

My two cents, folded to avoid bias.

I don't think there's a strong case for keeping the app easy to set up for external contributors at the moment. I haven't run a check in the issues and PRs, but my experience is that we receive only occasional interest from the community. At this point in time, I think we're better off focusing on making the app better for the users, by, among other things, shedding as much unnecessary code as possible. In the future, where the code is better and we removed various points of legacy and friction, we could revisit this. I think having the app opens source even if not contributor friendly is still a great things. It gives users a look under the hood of the apps they use and keeps us accountable.

[dcalhoun]

I see. Thank you for elaborating.

I agree with all that you shared. The ideal is a project that is approachable for the OSS community. We have limited resources currently and other higher priorities. If repairing and maintaining the setup scripts is significant effort, we should likely remove anything that is broken or confusing for the time being.

Long term, I think a setup script the enables developing against self-hosted sites is ideal. Enabling easy interfacing with Automattic services is less important for the community.

---

Are the setup scripts broken currently?

[kean]

Isn't there a significant overlap between rake init:oss and rake init? If they diverge in ways other than fetching the secrets (extra steps for internal devs), it's probably worth removing any unnecessary complication in the oss version. For ease of use, I'd also suggest rolling it into a single script and asking if you are an internal dev and have access to secrets during the setup process.

I think it's important to keep the oss version for hiring and for folks who may be interested in just running and debugging the app when evaluating it or starting on test projects before they get access to credentials (not sure if they ever do?).

There aren't a lot of external contributors, but we've had three new contributors just in this release:

## New Contributors
* @megmil made their first contribution in https://github.com/wordpress-mobile/WordPress-iOS/pull/23049
* @christianbilodeau made their first contribution in https://github.com/wordpress-mobile/WordPress-iOS/pull/23640
* @mrpolanco made their first contribution in https://github.com/wordpress-mobile/WordPress-iOS/pull/23645

[kean]

Ditch Rakefile
Convert the set up tasks to Makefile

The main problem with Ruby is Ruby versioning. If the script can run with the default version of Ruby pre-installed on macOS, I don't see any issues with keeping it as is.

[mokagio]

Mmm... I think we have a few different problems interacting here:

• Should we keep the app OSS friendly and provide automation that sets up the environment for OSS contributors?
• Do we need to use Rakefile or can we convert to Makefile. That is, is there any particular benefit that rake offers over make that makes it worth while to keep the tool and require OSS contributors to install the rake gem on their (system or custom) Ruby setup?
• How many of the current tasks in Rakefile are still relevant? How many might be relevant but we could do without for the sake of lower footprint?

Regarding rake vs make. I had a quick skim of the Rakefile and I don't see anything that would be too complex to convert to a shell script.

If we decide that Ruby should no longer be a requirement for day-to-day development (in particular by removing CocoaPods) then I think sticking with rake, would be counter productive. I have a feeling it's simpler to maintain a Makefile than a Rakefile that should run on system Ruby which no one using Ruby on a day-to-day basis uses (that I know of).