Swift extends CI to community hosts after merge
Community-hosted Swift CI begins with Fedora and ARMv7 Debian testing. Its post-merge execution model expands regression visibility while leaving host maintenance with volunteers.
A build that passes on the project's existing machines gives limited evidence about a compiler used on other systems. Swift's new community-hosted CI arrangement addresses that limit by connecting volunteer-maintained hosts to the project's testing system. The arrangement also makes a consequential choice about timing. The initial jobs run after changes merge.
The May 3 announcement introduces testing on Fedora and ARMv7 for Debian Stretch. Nicole Jacque and Mishal Shah describe community-hosted nodes as an extension of Swift's CI system. Volunteers can propose additional platforms through a pull request, and the volunteers maintain the host systems.
The same-day forum discussion supplies the operational detail missing from the short announcement. Shah confirms that community-hosted jobs currently run after merge. Pull-request testing is a plan dependent on the number of community-provided nodes. That distinction determines what a successful contribution to this infrastructure can establish.
I find Swift well designed, but a language's practical availability includes its build and test infrastructure. A port needs continuing evidence that changes still work on its platform. Giving that evidence a place in the project's CI is useful even when the first version detects regressions after integration.
Detection has a different role from admission
A pre-merge job can inform the decision to integrate a change. A post-merge job examines code that has already joined the branch. Both produce useful information, but they intervene at different stages. The initial community-hosted service offers the latter.
This means a proposed compiler change can enter the branch before a community machine discovers a platform-specific failure. The new service should not be described as a guarantee that every contribution passes Fedora or ARMv7 testing before merge. Shah's clarification directly rules out that interpretation of the launch.
Post-merge testing nevertheless changes the evidence available to maintainers. Without a recurring job on the additional system, a regression can remain unknown until someone builds that code independently. A job connected to the project's testing system provides a more regular point of observation. Its value is in making the result visible after integration.
The number of available hosts constrains how much testing the service can offer. Shah explicitly connects planned pull-request testing to node supply. That is a concrete resource dependency, not a promised date for expanding the service. More testing demand requires capacity to execute the jobs.
There is also a difference between identifying a bad change and deciding what to do about it. A failing job supplies evidence that a build or test did not meet its expectations on that host. Maintainers still need to determine whether the failure belongs to the source change, the host or its configuration. Adding a platform expands the cases the project can observe.
A volunteer contributes an operating system
The announcement assigns responsibility for host maintenance to the community member. A contribution therefore extends beyond offering a machine once. The system needs a host that remains available and capable of running its assigned work. This is an ongoing responsibility attached to the platform's testing.
A pull request to the community-hosted CI repository is the entry point for a new node. That provides a visible proposal for adding a platform. The project can consider the offered testing arrangement, while the volunteer remains responsible for maintaining the system on which it runs.
In another May 3 reply, Shah explains that Jenkins requires Java on the host and uses SSH to execute commands. This gives the arrangement a specific execution mechanism. The controller reaches the volunteer machine and runs the build work there.
That mechanism explains why node availability and host setup are part of the contribution. A compiler source checkout alone does not provide a functioning CI worker. The remote execution path and the software required by the controller also have to work. These are ordinary operational dependencies, but they determine whether the project's testing request becomes an actual result.
My concern about Swift build times makes the capacity question particularly relevant. A build job consumes a host for the duration of its work. A service that promises broader testing needs enough maintained machines to sustain the execution pattern it offers. The launch sensibly states the current pattern instead of implying unlimited pre-merge coverage.
Platform coverage should name the platform
The first announced additions are Fedora and ARMv7 for Debian Stretch. Those names describe different dimensions of portability. A Linux distribution identifies part of the userspace environment, while ARMv7 identifies an architecture. A result on one combination gives evidence for that combination.
The launch announcement does not claim that these additions establish support for every Linux distribution or every ARM system. Its wording is specific about the available jobs. Keeping that specificity matters when interpreting a compiler test result. A broad label such as Linux can conceal differences in the actual systems executing the tests.
This is also why community hosts can be useful alongside the main infrastructure. The additional systems expose combinations that a smaller centrally maintained set does not cover. The project can receive results from those hosts without taking over responsibility for operating every offered machine.
The arrangement allows platform interest and platform maintenance to meet in a concrete contribution. Someone who wants testing for an additional system can propose a node and undertake its maintenance. The announcement gives that work an official integration route, rather than leaving every platform's results in unrelated reports.
The initial service has a defined scope
The launch combines a central testing system with distributed host responsibility. Its initial execution policy is post-merge, and its initial added platforms are named. The forum clarification also identifies how broader pull-request testing might become possible, through additional community capacity.
Those facts are sufficient to assess what has changed without assuming a release-distribution promise. The announcement concerns continuous integration testing on additional platforms. It describes a way to run work and report its outcome, with a volunteer responsible for the execution host.
For someone maintaining a Swift port, that is a practical new route for recurring regression evidence. The immediate contribution is a proposed node that can participate in the existing post-merge service. Any later expansion into pull-request testing remains dependent on the resources Shah identifies in the launch discussion.