In my last post about automating Github actions workflow generation, I said I’d revived the old tool I wrote a while back, and got it working again (for some value of “working”).

I already figured that there was more to do, and then the post got an unexpected mention in iOS Dev weekly (thanks Dave!).

Once I’d got over my initial shock that anyone was paying attention (!), I decided that I definitely ought to spend a bit more time in the code… so that’s what I’ve been doing today.

Swift Versions

One thing that the tool lets you do if you want is to test your package against multiple versions of Swift.

If you’re just building macOS or Linux targets, it uses Swift Package Manager, and so can use Swiftly to choose the Swift version.

If you’re building for iOS/tvOS/visionOS/watchOS however, it has to use Xcode instead.

I had some code in the tool to support this; it works out which route to take, and then potentially chooses the right mac-os runner image, uses xcode-select to pick the right Xcode, and even if necessary downloads a toolchain installer and runs that to install a different toolchain into Xcode.

All of that was fine and dandy, but I realised that some of the macOS images I was trying to use on Github actions no longer exist, and some of the Xcode versions have been dropped. So quite a few of the old Swift versions I was supporting had no easy way to be tested.

There might be some way to work around this, but ultimately I came to the conclusion that just dropping support for these Swift versions was the pragmatic thing to do.

As a result, the oldest version of Swift that is now supported by the tool is 5.7. If you run the tool over a package using an earlier value for swift-tools-version, it will still generate a workflow, but it will default to testing with Swift 5.7 (and with the latest Swift).

Prettier Output

Something that always annoys me with CI is when the output is excessively wordy. Especially when it means that you have to wade through a ton of inconsequential logging to find the one piece of information that’s actually useful.

When I wrote the original tool, I was combating this for Xcode builds by piping the output through xcpretty.

Since then though I’ve discovered xcbeautify, which I prefer. It has the advantage of being written in Swift, and being easily installable using brew install xcbeautify.

So another thing I’ve done is switched over the tool to use it instead for any macOS jobs.

I pipe the output of xcodebuild into it, but also the output of swift test, since it understands that.

In addition to this, I’ve changed the swift build commands to take the --quiet flag.

All of this reflects my personal preference, which is to have very little output if everything is working, and just the errors if something is broken.

If anyone reading this is using the tool and wants a different approach, we could easily make it a config setting. Let me know (or open a PR!).

More Coming…

Other than that, I’ve tidied up the README a bit, and added some usage instructions if you just want to run the tool.

I did start taking a look at reviving my Swift tool plugin, but there’s more work to do there. I’m seeing some weird behaviour where the plugin hangs after it launches the tool, and as yet I’m not quite sure that I know why!

At some point I will do some more work on all of this…