By adding a `tools/sourcery` script that downloads and runs Sourcery via
Bazel.
Previously, unrelated changes might include modifications to the
generated comment headers because contributors' local versions of
Sourcery would be used, which we don't control.
Also move the CI job to Buildkite where the bazel server is usually
already warmed up and running.
* Use Ubuntu 20.04 to release Linux binaries
Using the latest version of Ubuntu leads to incompatibilities with `glibc` versions from LTS versions.
* Use Ubuntu 20.04 for Azure pipelines
We have 6 CI machines now and these should run faster on bare metal
machines with lots of stuff already cached, like starting with an
existing git repo.
Now that we have more Buildkite machines, these should be faster than
running on Azure Pipelines.
Also remove the `//bazel:xcode_config` configurations since they should
no longer be in use.
This is failing very often now due to FB11648454.
Given that we run these tests on macOS via SwiftPM and Bazel as well,
I'm satisfied with the amount of coverage we have on our tests without
this.
Added rules filtering options, like in the `rules` subcommand.
<img width="880" alt="generate-docs--help" src="https://user-images.githubusercontent.com/7829589/189372666-2f5aba62-57a1-49dc-9155-c60f9e085984.png">
To achieve reuse with `rules` subcommand:
- extracted filtering logic into `RulesFilter` (and write tests)
- extracted filtering command line parameters into `RulesFilterOptions: ParsableArguments`
This will unblock using Swift Concurrency features and updating to the
latest versions of Swift Argument Parser.
This won't drop support for linting projects with an older toolchain /
Xcode selected, as long as SwiftLint was _built_ with 5.6+ and is
_running_ on macOS 12+. So the main breaking change for end users here
is requiring macOS 12 to run.
However, the upside to using Swift Concurrency features is worth the
breaking change in my opinion. Also being able to stay on recent Swift
Argument Parser releases.
We now have two Buildkite agents thanks to a newly added M1 Mac mini
from MacStadium. Running the analyze job should be considerably faster
than the VMs that run on Azure Pipelines, although still slower than
if we were to run them with Xcode 13.2.1 because of the performance
regressions described in https://github.com/realm/SwiftLint/issues/3920.
* Add ability to focus on a specific test example
* Update CHANGELOG.md
Co-authored-by: JP Simard <jp@jpsim.com>
* Update CONTRIBUTING.md
Co-authored-by: JP Simard <jp@jpsim.com>
Co-authored-by: JP Simard <jp@jpsim.com>
Uses SwiftSyntax 5.5 on Linux when building with Swift 5.5. We use the 5.6 version of
SwiftSyntax when building with Swift 5.5 and 5.6 on macOS because we statically link
`lib_InternalSwiftSyntaxParser` thanks to
https://github.com/keith/StaticInternalSwiftSyntaxParser/releases/tag/5.6.
This keeps SwiftLint binaries portable across machines on macOS, regardless of
_where_ or even _if_ `lib_InternalSwiftSyntaxParser` is installed.
* Run TSan CI job with `--configuration release` to avoid stack overflows
* Add Swift 5.6 CI job
* Fix linker settings
* Disable Swift 5.4 CI jobs
* Remove SwiftLintFramework podspec
I couldn't find a single use in GitHub's search: https://github.com/search?q=SwiftLintFramework+filename%3APodfile+language%3ARuby+language%3ARuby&type=Code
Just not worth maintaining anymore.
* Change package swift tools version to 5.5
* Update docker_test to use Swift 5.5 image
* Clean up old Swift versions in SwiftVersionTests
Even though these older Swift versions should still be supported, these tests
can't be built against those versions so they're useless.
* Run docker commands with `--platform linux/amd64`
* Remove LinuxMain
It looks like tests are discovered dynamically on Linux as of recent
SwiftPM versions.
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.
* Require Swift 5.3 or higher to build
* Remove Swift Version Support tables from readmes
These weren't exactly accurate because SwiftLint should still work with
older Swift versions long after we update the minimum version of Swift
needed to _build_ the tool. So I doubt this table was very helpful to
anyone.
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
Swift 5.2 has been officially released for over 7 months now, there's no
reason to keep supporting earlier versions when _building_ SwiftLint.
However, SwiftLint still supports _linting_ back up to Swift 3.0.
* Update CI to run jobs with Xcode 11.0 to 11.4
In the process, remove CI jobs running with Swift 5.0.x and indicate
in the changelog that the next release will be the last one to support
building with Swift 5.0.x.
* fixup! Update CI to run jobs with Xcode 11.0 to 11.4
* fixup! Update CI to run jobs with Xcode 11.0 to 11.4
* fixup! Update CI to run jobs with Xcode 11.0 to 11.4
* fixup! Update CI to run jobs with Xcode 11.0 to 11.4
* Disable Swift 5.2 tests on Linux due to SR-12500
* Update ruby gems
Mostly to get jazzy 0.13.2 with Swift 5.2 bug fixes.
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.
This will allow us to run OSSCheck on a bare metal Mac, which should
make the OSSCheck performance results more reliable than running on
virtual machines from Azure Pipelines.
JP Simard
