-
Notifications
You must be signed in to change notification settings - Fork 680
CI: Add build check for WebAssembly SDK #3159
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
43fc72b
to
738186e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We sadly cannot accept this PR at this time. Currently WASM is not an officially supported platform by Swift and there is no official toolchain for it. This is something for the Platforms Steering Group to address. Once both issues have been solved we would love to add CI for WASM. cc @al45tair
Thanks for sharing! That's a good motivation to make it official :) |
@@ -88,3 +88,8 @@ jobs: | |||
name: Static SDK | |||
# Workaround https://github.com/nektos/act/issues/1875 | |||
uses: apple/swift-nio/.github/workflows/static_sdk.yml@main | |||
|
|||
wasm-sdk: | |||
name: WebAssembly SDK |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We sadly cannot accept this PR at this time. Currently WASM is not an officially supported platform by Swift…
@FranzBusch Curious what your thoughts are about allowing wasm builds into swif-nio
, but as optional
actions rather than required
?
This would improve visibility on wasm breakages without imposing a requirement for official support. Right now, contributors are likely a bit blind to any wasm breakages. If there is a way to improve awareness without imposing extra burden on contributors, feels like a win-win.
I believe we could make it optional by adding the following config to wasm-sdk
here.
continue-on-error: true
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @MaxDesiatov in case you have any insight on this as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@FranzBusch Curious what your thoughts are about allowing wasm builds into
swif-nio
, but asoptional
actions rather thanrequired
?
I'm fully empathetic on making sure we are not breaking WASM support. However, at this point we just can't use an externally produced toolchain here. That's why I would like to push the Platforms Steering Group on considering WASM as an official platform so that we can start producing official toolchains that we can use in our CI.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't look like it is a requirement in Pull Requests.
It might not look like it, but actually the Linux PR tests do do some WASM testing, and it is required to pass.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
6.2 and main
snapshots now have corresponding Swift SDKs distributed on swift.org https://www.swift.org/install/
@kateinoigakukun This is awesome, thanks so much! |
set -euo pipefail | ||
|
||
version="$(swiftc --version | head -n1)" | ||
tag="$(curl -sL "https://raw.githubusercontent.com/swiftwasm/swift-sdk-index/refs/heads/main/v1/tag-by-version.json" | jq -e -r --arg v "$version" '.[$v] | .[-1]')" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should query wasm-sdk.yml
from swift.org: https://github.com/swiftlang/swift-org-website/blob/main/_data/builds/swift-6_2-branch/wasm-sdk.yml and https://github.com/swiftlang/swift-org-website/blob/main/_data/builds/development/wasm-sdk.yml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I need to port foundation build first
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun @MaxDesiatov Just FYI, NIOCore wasm build is failing again for the following command
swift build --swift-sdk wasm32-unknown-wasi --target NIOCore
Most of the errors look like this:
…/swift-nio/Sources/NIOCore/BSDSocketAPI.swift:213:46: error: cannot find 'AF_INET' in scope
211 | @inlinable
212 | public static var inet: NIOBSDSocket.AddressFamily {
213 | NIOBSDSocket.AddressFamily(rawValue: AF_INET)
| `- error: cannot find 'AF_INET' in scope
214 | }
215 |
I think we probably just need to #ifdef
out the entire BSDSocketAPI.swift file from NIOCore for wasm builds.
However, the build passes using the p1threads
sdk:
swift build --swift-sdk wasm32-unknown-wasip1-threads --target NIOCore
I'm primarily just using the p1 sdk, so not sure if I'll worry about the older wasi sdk. But figured you'd want to know.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the latest main
has NIOCore compilation errors even for wasip1-threads
. I'll look into that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like the AF_INET
issue is gone now, the remaining issue is:
$ swift build --swift-sdk DEVELOPMENT-SNAPSHOT-2025-05-29-a-wasm32-unknown-wasi --target NIOCore
Building for debugging...
/Users/katei/ghq/github.com/swiftwasm/swift-nio/Sources/NIOCore/Channel.swift:461:19: error: type 'ChannelError' has no member 'multicastNotSupported'
459 | case let .illegalMulticastAddress(address):
460 | "Illegal multicast address \(address)"
461 | case let .multicastNotSupported(interface):
| `- error: type 'ChannelError' has no member 'multicastNotSupported'
462 | "Multicast not supported on interface \(interface)"
463 | case .inappropriateOperationForState:
I'll revisit this once I merge swiftlang/swift#82285
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun I have a PR approved to fix that multicastNotSupported error. It was just a preprocessor statement maintenance issue.
Not sure when this PR will be merged, but it should fix that last issue you mentioned.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun My PR to fix the NIOCore build us merged.
wasm-sdk: | ||
name: WebAssembly SDK | ||
# Workaround https://github.com/nektos/act/issues/1875 | ||
uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun I think to be able to test this locally with act, the following needs done.
Adding a TODO here as well just to make sure we don't forget to change the CI branch to main before merging this PR.
uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci | |
# TODO: Switch to this line before merging: | |
# uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@main | |
uses: kateinoigakukun/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci |
wasm-sdk: | ||
name: WebAssembly SDK | ||
# Workaround https://github.com/nektos/act/issues/1875 | ||
uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun Same thoughts here. Just a thought.
uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci | |
# TODO: Switch to this line before merging: | |
# uses: apple/swift-nio/.github/workflows/wasm_sdk.yml@main | |
uses: kateinoigakukun/swift-nio/.github/workflows/wasm_sdk.yml@katei/add-wasm-ci |
"platform":"Linux", | ||
"runner":"ubuntu-latest", | ||
"image":"ubuntu:jammy", | ||
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && $workspace/scripts/install_wasm_sdk.sh", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When I try to reference wasm_sdk.yml from another repo, this relative $workspace
ends up resolving to the calling repo rather than this repo. It looks like other repos do this type of thing, as I am seeing swift-distributed-tracing references to swift-nio workflows.
It looks like the solution for this used in swiftlang/github-workflows is to curl the script rather than using an environment reference.
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && $workspace/scripts/install_wasm_sdk.sh", | |
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && curl -s --retry 3 https://raw.githubusercontent.com/kateinoigakukun/swift-nio/refs/heads/katei/add-wasm-ci/scripts/install_wasm_sdk.sh | bash", |
The above contains a temporary path to @kateinoigakukun's fork that will work for testing this PR. The final path will need to reference main:
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && curl -s --retry 3 https://raw.githubusercontent.com/swiftlang/github-workflows/refs/heads/main/scripts/install_wasm_sdk.sh | bash",
"platform":"Linux", | ||
"runner":"ubuntu-latest", | ||
"image":"ubuntu:jammy", | ||
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && $workspace/scripts/install_wasm_sdk.sh", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same thought here:
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && $workspace/scripts/install_wasm_sdk.sh", | |
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && curl -s --retry 3 https://raw.githubusercontent.com/kateinoigakukun/swift-nio/refs/heads/katei/add-wasm-ci/scripts/install_wasm_sdk.sh | bash", |
Will need to be changed to the following before merging:
"setup_command":"apt-get update -y -q && apt-get install -y -q curl && curl -s --retry 3 https://raw.githubusercontent.com/swiftlang/github-workflows/refs/heads/main/scripts/install_wasm_sdk.sh | bash",
Add build check CI for WebAssembly SDK
Motivation:
It's very difficult to keep the code with WebAssembly/WASI compatible, and we need to apply some fixes sometimes #3156
Modifications:
Added a job to check if
swift build --swift-sdk wasm32-unknown-wasi
passes.Result:
Setting up the CI job makes it easier to detect such incompatibility before merging.