Add official workflows to CI

[finagolfin]

See what works

[finagolfin]

@Lukasa, wdyt, can you approve the workflow run?

[simonjbeaumont]

Was there something in this list that we don't already have coverage for that you'd like to see added?

I ask because this project, like many others our team maintains, tends to make use of the NIO matrix workflows where they exist, which offers a different enough UX for maintainers and contributors that we have yet to converge on a shared set.

It already covers some of the above, e.g. macOS and the static Linux SDK. We also have Windows CI, which is not mentioned in this list.

[finagolfin]

No, I simply enabled everything in these official workflows initially, to see if anything fails. I thought you could then pick out what you want, especially since they offer more versions and the snapshots builds are more up to date, eg Android builds with the latest snapshot bundles whereas the NIO-configured ones appear out of date.

These official GitHub workflows build for Windows and linux by default, as you can see in the results, so listing those two here is unnecessary.

[finagolfin]

Can you approve the workflow run, @simonjbeaumont?

[simonjbeaumont]

Can you approve the workflow run, @simonjbeaumont?

I have done so, but I think there's probably some drawbacks to us adopting swiftlang/github-workflows.

[finagolfin]

Such as? These swiftlang workflows would give much better coverage to this repo, such as adding Android and FreeBSD and the trunk snapshot of the static linux SDK would be much more recent than the old Dec. 1 2025 snapshot that the NIO-configured workflow uses.

Where there is overlap, we can always choose the best of each set of workflows to use.

[simonjbeaumont]

Such as?

The primary issue we had is they produce a lot of noise in the CI checks due to the way the matrix workflows are evaluated. For every matrix cell that we don't want, the workflows still generate a skipped check and one that has some distracting unexpanded variable expansions. Here's an example from a currently open PR in Swift Collections, which uses the swiftlang workflows https://github.com/apple/swift-collections/pull/704:

The NIO workflows do not do this. Instead they dynamically generate the matrix jobs based on config which means that only checks for things we enable show up.

IIUC there is an ongoing discussion about unifying the NIO and Swiftlang workflows and so the NIO (and adjacent projects) have been holding out.

These swiftlang workflows would give much better coverage to this repo ... Where there is overlap, we can always choose the best of each set of workflows to use.

I am sympathetic to the request though -- better coverage is important -- which is why I originally asked if there were ones you were specifically interested in. For those, we can evaluate the swiftlang workflows and/or update the NIO workflows to include the missing coverage.

...Android and FreeBSD and the trunk snapshot of the static linux SDK would be much more recent than the old Dec. 1 2025 snapshot that the NIO-configured workflow uses.

I believe we already have the static SDK check (including a nightly-main variant), although I just checked and presumably this is the snapshot issue you were mentioning:

** Discovering branch snapshot for branch main
** Snapshot unavailable: swift-DEVELOPMENT-SNAPSHOT-2026-08-08-a (Snapshot return code: 0, Swift SDK return code: 22)
---[ SNIP: many more attempts to resolve other tags ]---
** Snapshot unavailable: swift-DEVELOPMENT-SNAPSHOT-2025-12-11-a (Snapshot return code: 0, Swift SDK return code: 22)
** Discovered branch snapshot: swift-DEVELOPMENT-SNAPSHOT-2025-12-01-a

— (link)

That looks like a bug with the NIO workflow. Willing to accept it might be a bug that the swiftlang workflows do not have, but we should get it addressed independently in any event.

For Android, NIO does have a workflow we've adopted in many of the NIO-adjacent repos. Do you consider it to be sufficient? If so I expect that would be the path of least resistance here.

For FreeBSD, I think that's just setting the runner so potentially we could do this too here with the NIO workflow.

Let me do some more digging here. Curious what you think to the above in the meantime.

EDIT: Now filed apple/swift-nio#3711 to track the use of old static SDK.

[FranzBusch]

We are working with @shahmishal to unify the workflows between the NIO ones and the swiftlang provided ones. As Si mentioned, the swiftlang provided workflows have severe deficiencies that we do not want from a contributor experience perspective on our repositories. We really do want to unify but we need to solve those deficiencies first before we can move over.

There is a lot of automated tooling that we are using to update the branch protection rules based on how those workflows generate their checks. Moving just one repository over means our tools won't work for this repo anymore.

[finagolfin]

For every matrix cell that we don't want, the workflows still generate a skipped check and one that has some distracting unexpanded variable expansions.

I'm aware, Jake tried to fix that in swiftlang/github-workflows#208 but couldn't get it to work, swiftlang/github-workflows#234.

there is an ongoing discussion about unifying the NIO and Swiftlang workflows and so the NIO (and adjacent projects) have been holding out.

That merger has been publicly referenced before, but in the meantime I don't see any reason not to use both. I don't think the extra skipped checks shown in the UI are a big deal, provided we fix that in the coming months.

better coverage is important -- which is why I originally asked if there were ones you were specifically interested in.

I am only interested in better coverage generally: that's why I enabled everything in this pull, so we could compare the CI results and choose.

presumably this is the snapshot issue you were mentioning:

Yep, that's the outdated 2025 snapshot I noted.

For Android, NIO does have a workflow we've adopted in many of the NIO-adjacent repos. Do you consider it to be sufficient?

That NIO workflow was also outdated for the Android snapshots, last I checked.

Curious what you think to the above in the meantime.

Why stick with the NIO-based workflows for the platforms where they are missing or behind, when this simple config would add those instead? Other than the minor issue of noise from the skipped checks, I see no reason not to just use both until the merger is done.

There is a lot of automated tooling that we are using to update the branch protection rules based on how those workflows generate their checks. Moving just one repository over means our tools won't work for this repo anymore.

@FranzBusch, I don't know what you mean by "branch protection rules," but we could only require the NIO workflows to pass, as they are now, and simply add these swiftlang workflows for additional platform info. Would that avoid the problems you mention?

[FranzBusch]

@FranzBusch, I don't know what you mean by "branch protection rules," but we could only require the NIO workflows to pass, as they are now, and simply add these swiftlang workflows for additional platform info. Would that avoid the problems you mention?

Sadly no because it will add skipped workflows that @simonjbeaumont was referring to and which we really wanna avoid showing to contributors.

[finagolfin]

OK, if the skipped workflows shown in the GitHub UI are such a big deal to you, then these official swiftlang build workflows cannot be used in these server-side Swift packages at all.

Is there any timeline for merging the swiftlang and NIO workflows? It would seem we are stuck with two separate testing approaches until then. I don't think it would be a good idea to splinter resources by maintaining two separate approaches to the same GitHub workflows, so better to merge the two soon, if possible.

[simonjbeaumont]

Is there any timeline for merging the swiftlang and NIO workflows?

Good news! @rnro is working on exactly this and intends to opening PRs pretty soon.