* 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
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.
I believe this will completely remove the bot.
Rationale: https://github.com/realm/SwiftLint/pull/3385#issuecomment-784411782
> I've changed my mind on this. I believe this is solving the wrong
> problem. It can be very disappointing for users when their issues /
> PRs remain ignored by maintainers for a long time, but I think it's
> worse when issues / PRs are automatically closed, and I don't think it
> actually helps with the health of the project, or make maintainer's
> lives easier.
>
> I can't guarantee anything, but I am working on a plan to improve the
> maintainership of SwiftLint moving forward, and hopefully that can be
> more impactful when it comes to responsiveness to community issues and
> PRs, and I believe that's a better way to triage issues and PRs.