Hello Community,
I figured that it has been a while since I posted what has been going on in the world of the Azure CI that I've been running. Sadly, I've not been able to spend as much time as I would like on the Swift work recently, but, I've made some improvements of note still.
PR Testing
Due to the consistent failures on Android and Windows, I have finally managed to setup enough infrastructure to be able to do PR tests on these builds as well (though they need to be manually triggered ATM). For those working on Swift who would like to occasionally run PR tests for Windows or Android, I'm happy to provide access to the Azure instance.
CI CI
I have been slowly migrating the rules from being pulled from Azure's mirror of the CI rules to GitHub directly. This makes it easier to manage the rules, but also enables a much easier approach to testing the CI: PR testing to do CI for the CI system itself. It does require a request from an authorized user, but does enable a way for others to be able to contribute more easily.
Android CI
The builds on Azure now are building the Swift standard library, libdispatch, foundation, and XCTest libraries for android across x86, x86_64, armv7, and aarch64. These are also pretty stable. I would like make further improvements to this to see testing added to this so that we can have more coverage.
Windows CI
Windows CI is still not in the state that I would like. I'm not a DevOps person, so it takes me quite some time to figure out the best way or even a way to achieve some of the functionality I would like to see. Currently, the builds are very repetitive, and do not really do a very good job of reusing the rules. Additionally, the MSI generation is slow and as a result does not occur as frequently as it should/could be done. I have ideas on how to improve some of this, but, would love some help with that.
One of the bigger things is that I have finally got libdispatch tests enabled on CI, so we should be able to track regressions better now, particularly since we finally have most of the tests working on Windows thanks to help from @adierking. I hope to see the work that @gmittertreiner has been helping with lead to similar benefits on Foundation, allowing us to run the test suite on the CI hosts as well.
In the mean time, I have managed to get the Windows SDK (@jrose, yes, we need to figure out the proper name for that) setup to build on x86, x86_64, ARMv7, and ARM64. Unfortunately, these builds have been failing due to issues with clang/LLVM that I need to look into still. The reported failures on the status page is due to the other architectures, the only current stable platform seems to be x86_64 (funny given that I had brought up x86 first).
Windows Build Failures
ARM64: Variadic Function Validation Failure - I believe that my original checks for the variadic signature in C was overly strict for the MSVC behaviour. This is something easy to fix, I hope to be able to get to this soon
X86: Calling Convention Failure - clang fails to properly handle a __swiftcall__ function which is similar to stret, which results in the frontend asserting as the type does not have a copy ctor or a move ctor.
ARMv7: Missing CodeView Register Mapping - I have added the mapping for the register file to CodeView to enable being able to generate basic Debug Information for Windows ARMv7. However, that change hasn't been backported to the Swift fork since it ended up being less than a straight cherry-pick due to the extreme divergence between the top of tree and the fork. I am hoping that @dexonsmith, @Nicole_Jacque are able to improve the situation there soon.
I hope that I have covered most of the details, but, a lot of work is still going on to improve the experience for developers. There are lots of avenues for others to contribute. Additionally, I hope that these updates tend to be useful for others following the work to get an idea of where things stand.