Add CI for example projects#37
Conversation
|
Note that this PR would require that actions be enabled for this repository. |
digitalby
left a comment
digitalby
left a comment
There was a problem hiding this comment.
Nice PR, the install flow mirrors Getting Started nicely and the version-override hooks are clean. Dropping a pile of nits below, nothing blocking, feel free to ignore any that feel unhelpful.
|
@shahmishal Could you turn on actions in the settings for this repo so I can iterate on testing the GitHub workflows? |
|
Would anyone from @swiftlang/github-workflows-contributors like to give this a quick review pass? If not, I'll merge in the next couple of days. A representative successful run can be found at https://github.com/marcprux/swift-android-examples/actions/runs/25459566238 |
| strategy: | ||
| fail-fast: false | ||
| matrix: | ||
| swift_version: ["6.3", "nightly-main"] |
There was a problem hiding this comment.
That would expand the matrix from 2⁴ to 2⁵ entries, which is already pushing the limits given that GH actions can only have 5 concurrent macOS runners for public repos (and so it is already taking a very long time to run the CI).
I'm not entirely opposed to adding it if you think that it is valuable, but I personally think that if the projects build with 27 and 30, then we are probably also good for the in-betweens.
There was a problem hiding this comment.
Your math is off: you currently have 8 jobs running on macOS, this would add 4 more, ie 12.
Adding another NDK version on top of this would get us up to 18 jobs. Considering how rarely we update this repo, this would really only be run once daily, so I think the extra coverage is worth it.
Once the LTS NDK 30 releases, we can drop all the older unsupported NDKs, and the nightly 6.3 snapshots too once they stop around the same time, in a month or two.
There was a problem hiding this comment.
OK, I've added nightly-6.3 and ndk29 (since 28 is no longer listed at https://developer.android.com/ndk/downloads/) to the mix.
| fail-fast: false | ||
| matrix: | ||
| swift_version: ["6.3", "nightly-main"] | ||
| ndk_version: ['r27d', 'r30-beta1'] |
There was a problem hiding this comment.
28c would be good too, until 30 is out.
| workingDir = layout.projectDirectory | ||
| executable(getSwiftlyPath()) | ||
| args("run", "swift", "build", "+${swiftVersion}", "--swift-sdk", info.triple) | ||
| args("run", "swift", "build", "+${swiftVersion}", "--swift-sdk", info.triple, "--build-system", "native") |
There was a problem hiding this comment.
This should work with the default build system now, not working?
There was a problem hiding this comment.
No, not yet. The build works fine, but the .so files are being output in a new location that we will need to accommodate. We are working it out, the change in the build folder layout is going to require some more logic that I'll tackle in a future PR.
finagolfin
left a comment
finagolfin
left a comment
There was a problem hiding this comment.
Thanks for setting this up, Marc, just some suggestions for better test coverage.
It's too bad you had to do all this from scratch and couldn't just use the official workflows: what do you think about upstreaming all this back there, at least as an apk build option?
We don't really have a consensus about how Swift code should be tested in the form of a packaged .apk yet. These examples (contributed by various people) all have their own individual packaging setups; they are all app-oriented, and they all bring gradle baggage along with them, which I think we'd like to avoid for lightweight testing of pure swift packages in I do think that we will eventually want to converge on the right way to test swift on Android, both inside and outside of a packaged .apk (which is especially relevant for |
|
I just merged and I notice that all 18 macOS jobs are running simultaneously and do not seem to be subject to the usual 5 concurrent job limit for free OSS action runners. @shahmishal, is this costing real money? If so, perhaps we can reconsider the matrix and pare them back a bit. |
4 participants
This PR adds GitHub CI that will install the Swift SDK for Android and build each of the individual projects.
It also lightly modifies the gradle build files to enable overriding the Swift version it uses with
SWIFT_VERSIONandSWIFT_ANDROID_SDK_VERSIONenvironment variables in order to enable building with versions other than the presumed 6.3 (including nightly toolchains, although those aren't currently enabled in the CI).Note that we manually install everything in accordance with the Getting Started guide rather than leaning on the Android SDK support in
github-workflows(swiftlang/github-workflows#172) because it is closer to the experience that an end-user would have, plus this CI supports building on macOS as well as Linux. Also, thegithub-workflowsis designed to build-and-test a normal Swift package against a given SDK, whereas this workflow only builds the Swift package indirectly via the gradle builds.A successful run can be seen at https://github.com/marcprux/swift-android-examples/actions/runs/24172716605
Closes #34