Yesterday I started moving SwiftLint's CI jobs from Azure Pipelines to
GitHub Actions, which has nicer integrations with GitHub's web UI and
feels nicer & more lightweight overall.
However, GitHub Actions has a serious limitation compared to Azure
Pipelines, which is that it only has 5x macOS job concurrency vs Azure's
10x ([see Twitter](https://twitter.com/simjp/status/1326592600393068546)).
This leads to significant queuing when merging PRs or pushing to PRs in
a short span, which is the main way I work on SwiftLint when catching up
on PR/issue backlog every few months.
A quick timing check showed that a PR using Azure Pipelines (#3825) took
26m 47s vs GitHub Actions (#3824) took 32m 31s. These PRs were opened at
a time when no other CI jobs were running, so even though Azure
Pipelines already took 6 minutes less to run than GitHub Actions, that
difference would be even larger if there had been other PRs triggering
CI jobs at the same time.
So I think the best move for the project for the time being is to stay
with Azure Pipelines for its CI. If GitHub ever increases its macOS
concurrency to match Azure Pipelines's 10x we can explore this again.
Try a few things:
1. Sort InclusiveLanguageRule terms since they're a Set and don't have
deteministic ordering (will definitely help)
2. Fetch remote at the beginning of the script (likely to help)
3. Only fetch remote once (likely to help)
4. Sort branch & master output before diffing (unlikely to help)
5. Change diff filter from `d` to `AMRCU` (no idea if it will help)
Xcode has supported Swift Package Manager projects natively since Xcode
11, which has been out for over a year, where you can use Xcode by
having it open the `Package.swift` manifest rather than a `.xcodeproj`
or `.xcworkspace`.
I've been primarily developing SwiftLint in Xcode using this approach
for over a year, and despite a few nitpicks I have, it's been a joy to
use.
So I'd like to completely remove the Xcode project along with things
that support it:
* `SwiftLint.xcworkspace`/`SwiftLint.xcodeproj`: Neither of these are
needed if we use `xed .` or `xed Package.swift` to develop SwiftLint
in Xcode.
* `Cartfile`/`Cartfile.private`/`Cartfile.resolved`/`.gitmodules`/`Carthage/`:
These were used to manage dependencies as git submodules for use in
the Xcode workspace, but that's no longer necessary if Xcode delegates
to SwiftPM to manage dependencies for us.
* Some scripts can be simplified, cleaned up or even completely removed.
* **Reduce duplication:** Rather than update dependencies or files in
multiples places, there will only be the package manifest and the
Podfile
* **Reduce merge conflicts:** This hasn't been too bad, but it's
occasionally a pain when trying to land old PRs
* **Reduce development overhead:** No need to manually make sure that
files in the Xcode project are sorted alphabetically
* **Reduce clone time:** No need to run
`git submodules update --init --recursive` anymore
I think this breaks Carthage users that pull in SwiftLintFramework as a
dependency in a Cartfile.
However I can't find any references to [`SwiftLintFramework` in any
`Cartfile` files on GitHub](https://github.com/search?q=swiftlintframework+filename%3ACartfile&type=Code&ref=advsearch&l=&l=)
so this doesn't appear to be worth continuing to maintain.
Resolves https://github.com/realm/SwiftLint/issues/3412
Current events have renewed the conversation in our community about the roles of terminology with racist connotations in our software. Many companies and developers are now taking appropriate steps to remove this terminology from their codebases and products. (e.g. [GitHub](https://twitter.com/natfriedman/status/1271253144442253312)) This small rule prevents the use of declarations that contain any of the terms: whitelist, blacklist, master, and slave. It may be appropriate to add more terms to this list now or in the future.
The new rules introduced in 0.39.0 that depend on SwiftSyntax have been temporarily removed as we work out release packaging issues.
* `prohibited_nan_comparison`
* `return_value_from_void_function`
* `tuple_pattern`
* `void_function_in_ternary`
See https://github.com/realm/SwiftLint/issues/3105 for details.
* Improve compilation time
Before this change, `trailingClosure` took 8.6s to type check.
After this change, it takes 31ms.
* Speed up type checking `isDecimal(number:)`
Before: 377ms
After: 2ms
* Speed up type checking testViolationMessageForExpressibleByIntegerLiteral()
Before: 285ms
After: 175ms
* Fix OSSCheck
More than just rules are in `Source/SwiftLintFramework/Rules/`
* Shim XCTUnwrap for Swift 5.0
Ruby's documentation mentions that `popen3` requires that you flush
stderr to prevent deadlocking:
> You should be careful to avoid deadlocks. Since pipes are fixed length
> buffers, ::popen3(“prog”) {|i, o, e, t| o.read } deadlocks if the
> program generates too much output on stderr. You should read stdout and
> stderr simultaneously (using threads or IO.select). However, if you
> don't need stderr output, you can use ::popen2.
The MIT license doesn't require that all files be prepended with this
licensing or copyright information. Realm confirmed that they're ok with this
change. This will enable some companies to contribute to SwiftLint and the
date & authorship information will remain accessible via git source control.
- Use same build directory to `branch` and `master` for incremental building
- Add options:
```terminal.sh-session
$ script/oss-check --help
Usage: oss-check [options]
--branch BRANCH compares the performance of BRANCH against 'master'
--iterations N iterates lint N times on each repositories
--skip-clean skip cleaning on completion
-v, --[no-]verbose Run verbosely
```
Juozas Valančius
