Introducing setup-swift: Setup Swift environment with GitHub actions

Community Showcase
, , ,
1

Hey everyone!

I am excited to share my latest project setup-swift that will allow hassle free Swift environment set up. You can just add the action without any input parameters to use latest version:

- uses: SwiftyLab/setup-swift@latest

Or specify swift version:

- uses: SwiftyLab/setup-swift@latest
  with:
    swift-version: "5.1.0"

While there are alternate actions that provide such functionality, this action provides you some additional features:

  • Stays up-to-date with latest snapshots as soon as they are published in swift.org.
  • Allows you to use latest development snapshots by enabling the development flag:
    - uses: SwiftyLab/setup-swift@latest
  with:
    development: true
    Or you can specify the development version directly:
    - uses: SwiftyLab/setup-swift@latest
  with:
    swift-version: '5.9'
  • Supports macOS and Linux completely, and has limited support for windows.

I created this action to run CI with Swift 5.9, hope you will find this useful as well. Let me know what additional features or improvements you would like to see.

Currently I am looking for help with windows support as I don't have access to windows machine and latest versions(5.7 and 5.8) are failing with this error when running swift --version:

The process 'C:\hostedtoolcache\windows\swift-5.8.1-release-windows\5.8.1\x86_64\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swift.exe' failed with exit code 3221225781

Would appriciate any help I can get with this.

5 Likes
2

For your specific problem, swift.exe on Windows requires the Swift runtime since 5.7, and %Path% may not be updated (or reloaded) correctly in a GitHub actions container, so you need to append it manually. For reference, check out https://github.com/compnerd/gha-setup-swift/blob/cdd5104c49cc3174aa7d33a16fd0a5f8d977f119/action.yml#L68-L78.

I feels that there're too many implementations for setting up Swift with GitHub actions, and almost each of them just lacks one or a small few of features. If we can join the community effort (perhaps as a SSWG project) to make one standardized implementation, this could be the most efficient. We need support for other CI environments, eg. GitLab CI, more eagerly than yet another GitHub action.

Here's a list of other known "Setup Swift on GitHub Actions" projects:

  • compnerd/gha-setup-swift:
    • Written in Bash / PowerShell scripts;
    • Works perfectly on Windows;
    • Only supports GitHub-hosted runner;
    • Supports Windows(>=5.4.2), Ubuntu(?) and macOS;
    • Supports arbitrary toolchain, but requires verbose input;
    • Not properly tagged, only main is usable.
  • slashmo/install-swift:
    • Written in Bash script;
    • Built-in caching support;
    • Supports Ubuntu and macOS;
    • Supports development snapshots.
  • swift-actions/setup-swift:
    • Written in Typescript;
    • Built-in caching support;
    • Implements strict GPG checking;
    • Supports installing latest minor (maintainer involved);
    • Supports Windows (<5.7), Ubuntu and macOS;
    • Only supports release versions.
  • YOCKOW/Action-setup-swift
    • Written in Javascript and Typescript;
    • Based on swiftenv;
    • Only supports macOS;
    • Supports development snapshots;
    • Supports installing latest minor (depending on swiftenv maintenance).

I summed up of a list of missing key features:

  • Windows support: Only compnerd/gha-setup-swift supports Windows perfectly. swift-actions/setup-swift was almost there but it met the same problem with you.
  • General Linux support (besides Ubuntu): Missing from all the listed implementations, but I'm happy to see SwiftyLab/setup-swift getting partial support for other Linux distribution through getos, and at least CentOS might work.
  • Installing latest minor: This is one of my favorite from swift-actions/setup-swift, but now it still requires maintenance of a version list. Perhaps the Swift Website Workgroup can set up a standardized API for retrieving release information, which CI actions (and Swiftly!) can benefit from.
4 Likes
3

I entirely agree with this sentiment. I am partially to blame here for I do have an action of my own, but I do find that it was easier to do that to ensure that the Windows changes were kept up to date and the extension was simple enough where I could quickly iterate for Windows changes.

Is there something special that needs to be done to support self-hosted runners? I don't have experience with this, and patches to improve this would be welcome.

It should also work with CentOS. Improvements to the platform support are welcome. I do admit that the Linux paths are not very well tested.

I really would like to see this improved. The current thing is really terrible and I think also redundant as I believe that the data can be inferred from just the full tag name. I've not figured out how to do that though and it is really annoying. I'd love to see this improved.

I'm sorry, I didn't realise the tagging was an issue. I'm more than happy to make newer tags whenever necessary. I've tagged 0.1.0 for the current main.

I would love to see this added as well, but I think that at least on Windows it adds more overhead (but if that is not the case, this would absolutely be amazing).

4

For your specific problem, swift.exe on Windows requires the Swift runtime since 5.7, and %Path% may not be updated (or reloaded) correctly in a GitHub actions container, so you need to append it manually. For reference, check out https://github.com/compnerd/gha-setup-swift/blob/cdd5104c49cc3174aa7d33a16fd0a5f8d977f119/action.yml#L68-L78 .

Thank you, will have a look at this.

I feels that there're too many implementations for setting up Swift with GitHub actions, and almost each of them just lacks one or a small few of features. If we can join the community effort (perhaps as a SSWG project) to make one standardized implementation, this could be the most efficient. We need support for other CI environments, eg. GitLab CI, more eagerly than yet another GitHub action.

I get it, I made this project to address this. Current list of supported features by SwiftyLab/setup-swift:

  • Written in Typescript.
  • Built-in caching support.
  • Implements strict GPG checking.
  • Supports installing latest minor (automated).
  • Supports Windows (<5.7), Ubuntu and macOS;
  • Supports both release and development snapshots (both can be used by just specifying version).

Yes actually I implemented Windows support in swift-actions/setup-swift and using the same implementation in this project. I will work on perfecting the windows setup.

  • Installing latest minor: This is one of my favorite from swift-actions/setup-swift , but now it still requires maintenance of a version list. Perhaps the Swift Website Workgroup can set up a standardized API for retrieving release information, which CI actions (and Swiftly!) can benefit from.

SwiftyLab/setup-swift supports this, but instead of maintaining a static version list it uses swift.org as a submodule and receives the version data dynamically. This ensures SwiftyLab/setup-swift always has the latest snapshots available.

5

For your specific problem, swift.exe on Windows requires the Swift runtime since 5.7, and %Path% may not be updated (or reloaded) correctly in a GitHub actions container, so you need to append it manually. For reference, check out https://github.com/compnerd/gha-setup-swift/blob/cdd5104c49cc3174aa7d33a16fd0a5f8d977f119/action.yml#L68-L78 .

Thanks for this, I have added runtime path, and now windows setup is working upto current stable version.

But for current development snapshots it is failing, seems like the installation path is different.
Does the development snapshots have different path than stable ones, or is the path being changes from next versions?

The reason this is specific to SwiftyLab/setup-swift is cause it is the only action that implements tool caching for windows as well, hence knowing the installation path is necessary here. Do you know if windows installer supports custom installation path? That would be beneficial for resolving these issues as well.