Set up SwiftLint as a standalone build plugin#23996
Conversation
|
| App Name | Jetpack Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr23996-5ea934a | |
| Version | 25.7.1 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 5ea934a | |
| App Center Build | jetpack-installable-builds #10536 |
|
| App Name | WordPress Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr23996-5ea934a | |
| Version | 25.7.1 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 5ea934a | |
| App Center Build | WPiOS - One-Offs #11504 |
8df602d to
f692687
Compare
| let animatedImage = image as? AnimatedImage, | ||
| animatedImage.gifData != nil | ||
| { | ||
| animatedImage.gifData != nil { |
There was a problem hiding this comment.
Moving up from version 0.54.0 brought up this and other opening_brace violations.
Might be related to the rule having been rewritten in version 0.55.0 and then updated in version 0.57.0.
| @@ -1,10 +1,11 @@ | |||
| swiftlint_version: 0.54.0 | |||
| swiftlint_version: 0.58.2 | |||
There was a problem hiding this comment.
We cannot use 0.54.0 because it's not available as a built tool plugin, see https://github.com/SimplyDanny/SwiftLintPlugins/releases
Given that, it makes sense to use the latest available version. But even if we didn't want to:
- 0.58.0 and 0.58.1 have a bug where the Docker image reads the wrong version, so we cannot use them
- 0.55.0 does not have the
--working-directoryoption which we need
af75c45 to
db78e12
Compare
kean
left a comment
There was a problem hiding this comment.
This is a bit of an argument from authority, which is why I'm leaving it last and using it more as a reinforcement of my conclusion than an explanation, but realm/SwiftLint#5207 (comment)
I concur. It should be used only when the code requires a tool to compile – mainly code generators.
| @@ -0,0 +1 @@ | |||
| .build | |||
There was a problem hiding this comment.
I'd add it to the .gitignore file in the root directory.
| name: "BuildTools", | ||
| platforms: [.macOS(.v10_13)], | ||
| dependencies: [ | ||
| .package(url: "https://github.com/SimplyDanny/SwiftLintPlugins", exact: loadSwiftLintVersion()), |
There was a problem hiding this comment.
Does the version numbers have to be in .swiftlint.yml? Are there any other roadblocks for simply defining the version here in the package:
.package(url: "https://github.com/SimplyDanny/SwiftLintPlugins", exact: "0.58.2"),
There was a problem hiding this comment.
.swiftlint.yml needs to specify the SwiftLint version the configuration expects
We don't have to read the version from there here, but I find it nice to have a single source of truth.
We could duplicate the value here, but we might run into some annoying issues if the version defined here diverges from the one in the config so that we end up with CI running a different version than local and giving different feedback.
5189e4b to
d7d0010
Compare
This way, we'll be able to add additional checks without messing up the project file.
The previous version, 0.54.0, is not available as a plugin. And of all the version available via the plugin, this is the only one that actually works.
8479673 to
5ea934a
Compare
|
I thought I'd merged this already 😳 Apologies for letting this sit in the limbo for so long... |
| # For some reason, running when trying to archive, via CLI, results in a compilation failure. | ||
| # | ||
| # fatal error: module 'WordPressSharedObjC' in AST file '/path/to/DerivedData/ModuleCache.noindex/EQUUY9BHSJ5N/WordPressSharedObjC-5G93B85NZ09I.pcm' | ||
| # (imported by AST file '/Users/gio/Developer/a8c/wpios/DerivedData/WordPress/Build/Intermediates.noindex/ArchiveIntermediates/WordPress Alpha/PrecompiledHeaders/WordPress-Bridging-Header-swift_1L0UBHDEION2G-clang_EQUUY9BHSJ5N.pch') | ||
| # is not defined in any loaded module map file; | ||
| # maybe you need to load '/Users/gio/Developer/a8c/wpios/DerivedData/WordPress/Build/Intermediates.noindex/ArchiveIntermediates/WordPress Alpha/IntermediateBuildFilesPath/GeneratedModuleMaps-iphoneos/WordPressSharedObjC.modulemap'? | ||
| if [ "${CONFIGURATION}" != "Debug" ]; then |
There was a problem hiding this comment.
Nit: if the error is really related to archiving vs just building, as opposed to debug vs release, I think you could have used the ${ACTION} env var to check for build vs archive? 🤷
Co-authored-by: Olivier Halligon <olivier.halligon@automattic.com> Follows up on #23996 (comment) Makes the logic more precise, given the error occurs when archiving.
Co-authored-by: Olivier Halligon <olivier.halligon@automattic.com> Follows up on #23996 (comment) Makes the logic more precise, given the error occurs when archiving.
* Bypass SwiftLint using `ACTION` instead of `CONFIGURATION` Co-authored-by: Olivier Halligon <olivier.halligon@automattic.com> Follows up on #23996 (comment) Makes the logic more precise, given the error occurs when archiving. * Add note about inconsistent failure when archiving locally


#23958 removes CocoaPods from the project setup, but with SwiftLint also goes away.
This PR re-introduces SwiftLint, fetching it using the SwiftPM plugin repo but then calling the binary directly via the existing SwiftLint aggregate target (which calls
rake lintunder the hood.I considered using the plugin setup, see #23990, but didn't go ahead with it because:
For reference, this setup is inspired by SwiftFormat.
I considered fetching SwiftLint directly instead of the plugin, but doing so would have required compiling SwiftLint from source to run it, which was very time consuming.
Finally, it crossed my mind to keep the old CocoaPods setup for SwiftLint. I started going down that path in #23998 but stopped once I noticed that the performance using the setup in this PR were comparable to those on
trunk, see #23999Given that removing CocoaPods whether to build the app or for tooling, brings us closer to our goal of no longer depending on Ruby for product-development tasks, I'd rather stick with this Swift-only approach.
Note
I'm having issues archiving the app via Fastlane, even though
vanillaand Xcode work fine. I'm investigating...xcodebuildApart from being unsure about the error itself, I don't understand is how the changes in this PR might be affecting the build that way...
Updated I haven't fixed the issue but I have a workaround that I like and that I think we should consider in order to merge this PR and then move forward with #23958
The TL;DR is that the error occurs only when building builds with configuration Release or Release-Alpha, so I told the script that runs SwiftLint to only run on Debug builds. We have CI covering us when building a different configuration because it runs the standalone linter. In fact, I also disabled the SwiftLint build phase in CI, to save time because of that.
Regression Notes
PR submission checklist:
RELEASE-NOTES.txtif necessary. N.A.UI changes testing checklist: Not a UI PR.