For a little over a year, I have been collaborating with the open source community in bringing Swift support for Android up to the level that other platforms enjoy (namely Darwin and Linux), mainly thanks to the incredible job others did before me. Sadly, I will not be able to continue dedicating a lot of time to those efforts, and with this post I want to inform the community of people interested in Swift for Android.
About continuous integration.
As part of the Swift Community CI there are two machines running a partial Swift test suite with every commit to master. There's one for ARMv7 and one for AArch64. Those machines are still going to be available for the time being.
These machines do not execute the complete Swift test suite. The complete test suite will test both the compiler and the standard library implementation. In the machines we can test the compiler and some aspects of the stdlib, but we cannot run any compiled code targeting the Android devices, because the machines have no Android device attached to them. This means that by default for Android, instead of running the target
check-swift-android-aarch64, the machines run
A couple of pieces that are not build in these machines are the Swift corelibs (dispatch, XCTest, and Foundation). Limitations in the
build-script infrastructure make it impossible to cross-compile those. The products will normally compile, and for the most part they pass the tests and work, but building them in the CI is not possible at the moment (see below to learn who is continuously building those libraries for Android).
Additionally, these machines skip building many products beyond Swift, like SwiftPM, SourceKit-LSP and others, since those only apply to the machine that compiles the code, not the one that run it, and those products are already build by the Linux CI machines, and building them again will be a waste of resources.
What to do when the build breaks
Sadly, there's currently no way set up to execute the same suite of tests before the pull requests are merged, so normally one will notice problems with the builds after the pull requests are merged, and not before. Fortunately there are not that many breakages thanks to the awesome work of the rest of the contributors, but there exist from time to time. Since the machines are quite fast (it takes about an hour to build and test), if the breakages are recent, it is quite easy with Jenkins Console Output and the Jenkins Build Changes to figure out what happened. If the breakages are not recent (so the first build that failed is already discarded from the limited history of 20 last builds), one should focus on the Console Output only.
Most of the breakages this days is a modification on the test files: either someone added a new test, or someone modified a test that didn't need to execute on the target. In this case, the fix is really simple, since it just means adding
// REQUIRES: executable_text in the test file. Examples of these kind of fixes are #29235, #28751, or #26759.
In other cases the fixes are more involved. One example is 32 bits compatibility: the main platforms (Darwin and Linux) do not care that much anymore about 32 bits, having evolved to 64 bits in most cases, so in some occasions a test will be written only for 64 bit machines, and have to be adapted for the ARMv7 32 bit processor (for example in #28542). Other examples are missing checks for Android: the test are written for Darwin and Linux (since those are the machines that are checked by the official CI), but are missing other platforms like Android or Windows. These cases are harder to catch, because sometimes they are silent: if the checks are not there, the test harness will not notice any wrong checks (an example of this case is #28422). Most of the other cases will be one off, that might need more thinking or investigation. A good place to start might be searching for "android" in the closed PRs of the Swift project.
A final case for breakage will be that the machine itself broke. This hasn't happen in a long time, but because life has a sense of humor, I found a breakage like that while I was writing these lines (#29244 introduced a new dependency for the
build-script which wasn't installed in the machine). In this cases, the only way of fixing these kinds of problems is having access to the machine itself, which means that I will need to be involved. More details about that below. I think there are big changes coming to the
build-script, so I will try to keep an eye for the next couple of weeks, just in case anything else breaks.
How to know when the build breaks
Sadly there's no good way to be notified of the build breakages that I know. I used to visit https://ci-external.swift.org/ every morning to check that the builds weren't in the previous 24 hours. I end up using an RSS reader, and subscribed to the RSS feeds of the builds (ARMv7 and AArch64). At least I was getting a visual notification if new builds were happening. It will be ideal to have a push system, but the current system doesn't seem to allow such thing.
How to communicate with me if necessary
In the case that something goes horribly wrong with the machine, or there's some problem that can only be fixed with access to the machine, there will be no other way to fix things than contacting me.
The best way will be these forums: mention me (maybe as a comment to this post) and I will try to answer as soon as I am capable. This might mean that I will normally be able to help on weekday evenings/nights and some weekends (Pacific Coast time zone), and sometimes one is away from a working computer for long periods of time, so please be patient if I don't answer right away. I hope, however, that most things will not need my involvement, and that the community will be able to fix them by themselves.
A note about Azure
Since early last year, @compnerd has been working on an alternative Swift CI hosted in Azure DevOps. It was initially intended for the Swift for Windows builds, but it has grown in the meantime to build many other products.
One of the products is a complete Android SDK, including dispatch, Foundation and XCTest, which are not build in the Community CI. While I think these builds do not test the standard library at all (not even the non executable tests), or the Swift corelibs, it gives a little bit of signal about their health. If you are interested in helping, it might not be bad to have an eye on those builds as well.