Introducing swift-build - GitHub Action for testing Swift on multiple platforms and versions

I’ve built an easy to use Github Action for building and testing your Swift Packages. I've been using this for my current for over a year and I'm loving how simple it is to get started using it.

I especially love the simplicity to setup a matrix for multiple versions of Swift, Xcode, iOS, macOS, or Linux. Please let me know if you have any feedback or thoughts.

You can read more about how it works here:

2 Likes

Hi, did you know about the GitHub Actions: New reusable workflows repository, which was announced a year ago? If so, what functionality was missing for you?

The repository is located here: GitHub - swiftlang/github-workflows

2 Likes

I just recently heard about them. My understanding is those are targeted for the internal swiftlang repos as opposed to the general public. I could be wrong.

The goal for me was to reduce special exceptions for different OSes, platforms, Xcode and Swift versions especially when using the matrix.

You’re right that these are primarily intended for Swift language repositories. However, some Swift repositories, like swift-argument-parser, are essentially the same as other general-purpose repositories. If there are clear ergonomic or testing improvements that could benefit both, I don’t see any reason not to adopt them.

1 Like

If that’s what works for you go for it.

My primary goal in creating this is simplifying GitHub workflow matrix for multiple variations. You can take a look at how I use it with SyntaxKit here:

This seems to be limited in platform support - it doesn’t seem to cover Windows. So far, I’ve found that the best option IMO is still GitHub - compnerd/gha-setup-swift: Setup Swift (on Windows) on GitHub Actions Builders for setting up the environment to be able to support all the various platforms.

1 Like

Yes I know :pensive_face:

I tried several things and ran into issues. First doing it manually then using compnerd/gha-setup-swift. I’m not sure what I am doing wrong so I’m open to suggestions. Here’s the last build error I received.

C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\intsafe.h:227:64: error: invalid suffix 'i128' on integer constant

 225 | #define DWORD64_MAX     0xffffffffffffffffui64




 226 | #define UINT64_MAX      0xffffffffffffffffui64




 227 | #define INT128_MAX      170141183460469231731687303715884105727i128




     |                                                                `- error: invalid suffix 'i128' on integer constant

 228 | #define UINT128_MAX     0xffffffffffffffffffffffffffffffffui128




 229 | 






C:\Program Files (x86)\Windows Kits\10\include\10.0.22621.0\shared\intsafe.h:228:59: error: invalid suffix 'ui128' on integer constant

 226 | #define UINT64_MAX      0xffffffffffffffffui64




 227 | #define INT128_MAX      170141183460469231731687303715884105727i128




 228 | #define UINT128_MAX     0xffffffffffffffffffffffffffffffffui128




     |                                                           `- error: invalid suffix 'ui128' on integer constant

 229 | 




 230 | #undef SIZE_T_MAX




error: fatalError

Ah, this is a “fun” issue. The i128 extension (and the ui128) are MS extensions. I’ve never been able to narrow down when this occurs. Instead, I just fixed clang upstream, so the newer toolchain images should not encounter the issue anymore.

edit: Lex: add support for `i128` and `ui128` suffixes by compnerd · Pull Request #130993 · llvm/llvm-project · GitHub is the upstream PR

Which parameters do I need to change exactly?

Just the swift-version and swift-build to 6.2 development?

Yes, the 6.2 development I think should include the fixes.

Yeah I tried that:

No luck. Feel to play around with it and put a PR.

lld-link: error: could not open 'kernel32.lib': no such file or directory

It seems that the SDK version installed is likely the issue. If you look at the invocation:

10.0.26100.0 is the version being used. This was removed in the latest VS upgrade. Updating to 10.0.22621.0 should fix the issue.

I’m surprised no one brought this up, but you don’t think the name of this will cause confusion with GitHub - swiftlang/swift-build: A high-level build system based on llbuild, used by Xcode, Swift Playground, and the Swift Package Manager , which is already confusing with SwiftPM’s swift-build executable target?

5 Likes

Which are confusing with GitHub - compnerd/swift-build: Alternate Swift Builds which is extremely old as well :slight_smile:

1 Like