Test PR for Danger + SwiftLint

[mokagio]

Expecting a couple of Danger comments about duplicated imports because of 61ca9925ba5e01fed26c3d206741bdd704f6efa0 .

[dangermattic]

Danger has errored

[!] Invalid Dangerfile file: swiftlint is not installed. Updating the Danger gem might fix the issue. Your Danger version: 9.3.2, latest Danger version: 9.4.2

 #  from Dangerfile:41
 #  -------------------------------------------
 #  swiftlint.binary_path = './Pods/SwiftLint/swiftlint'
 >  swiftlint.lint_files inline_mode: true
 #  -------------------------------------------

Generated by :no_entry_sign: Danger

[mokagio]

@iangmaia this test PR raises an interesting question. How to use SwiftLint with Danger if Danger does not run on macOS.

Any ideas?

See also paaHJt-4l3-p2

[wpmobilebot]

📲 You can test the changes from this Pull Request in WordPress Alpha by scanning the QR code below to install the corresponding build.

	App Name	WordPress Alpha
	Configuration	Release-Alpha
	Build Number	pr22408-61ca992
	Version	24.0
	Bundle ID	org.wordpress.alpha
	Commit	61ca9925ba5e01fed26c3d206741bdd704f6efa0
	App Center Build	WPiOS - One-Offs #8461

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[wpmobilebot]

📲 You can test the changes from this Pull Request in Jetpack Alpha by scanning the QR code below to install the corresponding build.

	App Name	Jetpack Alpha
	Configuration	Release-Alpha
	Build Number	pr22408-61ca992
	Version	24.0
	Bundle ID	com.jetpack.alpha
	Commit	61ca9925ba5e01fed26c3d206741bdd704f6efa0
	App Center Build	jetpack-installable-builds #7484

Automatticians: You can use our internal self-serve MC tool to give yourself access to App Center if needed.

[iangmaia]

@iangmaia this test PR raises an interesting question. How to use SwiftLint with Danger if Danger does not run on macOS.

The problem in this case is using SwiftLint from Cocoapods, binary_path = './Pods/SwiftLint/swiftlint', but you need to install the pods first. But still... you'll likely face the same problem I did:

./Pods/SwiftLint/swiftlint: 1: Syntax error: word unexpected (expecting ")")

Side note: if you don't provide any binary to danger-swiftlint, it will automatically download a version (that you can specify in Gem install time) from GitHub and run it.

Anyway, the error above I assume is due to the plain Ubuntu environment, perhaps for not having the Swift runtime. There are official Docker images (ghcr.io/realm/swiftlint:latest) we could use on GHA and that would work... except they don't have a proper Ruby setup, so it eventually fails:

A solution to this could be maintaining our own Docker Swift+Ruby image (there are a few around, like this old one, but none seemed actively maintained).

Though now I'm also wondering what's the best alternative, taking your post into account and a few discussions I had. There are some obvious advantages of SwiftLint via Danger:

• Easy setup, as danger-swiftlint is already in Dangermattic and it's just a matter of adding the call in the Dangerfile
• If a project is using Cocoapods, it's easier to tie the version used by the build (e.g. as an Xcode step, also by the devs) to the version running on CI
• Inline comments on PRs

I'm currently facing the exact same question on PocketCasts iOS, as they previously had SwiftLint running via Danger, though it was probably silently failing at least for a while. For now I'm going on the route of moving SwiftLint to a Buildkite step instead, annotating the Buildkite build. In addition to this, we could also have a build step to run on the local machines (and not on CI), similarly to what was discussed in the thread you mentioned. It worked alright:

One question here would be how to keep the SwiftLint version in sync. A solution could be using a .buildkite/shared-pipeline-vars, as discussed on paaHJt-5Rr-p2, and have the Podfile read and use the version from there as well.

I'm not completely decided either way yet, but as we lack a proper Swift+Ruby image for running Danger, I just went the Buildkite route. What do you think?

[mokagio]

@iangmaia

For now I'm going on the route of moving SwiftLint to a Buildkite step instead, annotating the Buildkite build. In addition to this, we could also have a build step to run on the local machines (and not on CI), similarly to what was discussed in the thread you mentioned.

Looks like we converged to a similar solution. See https://github.com/wordpress-mobile/WordPress-iOS/pull/22413 😄

One question here would be how to keep the SwiftLint version in sync. A solution could be using a .buildkite/shared-pipeline-vars, as discussed on paaHJt-5Rr-p2, and have the Podfile read and use the version from there as well.

That would definitely work as a way to have a single source of truth. The approach I took so far is to use Podfile as the source of truth for the version and for downloading the binary, and make everything that needs to use SwiftLint use the binary CocoaPods got.

I haven't tried yet, but I assume something similar could be done if the source of truth and downloader for SwiftLint was SPM.