Release swift bindings #460
Conversation
|
How would this work with react-native's weird dependence on CocoaPods. My understanding is that |
@neekolas This is no longer relevant because we can not get rid of |
| name: Release Swift Bindings | ||
|
|
||
| on: | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Updated the release swift bindings to just go on manual triggers for now.
*Note this can be triggered before this PR is merged to main using the gh cli:
gh workflow run workflow-name --ref branch-name
* chore: gen protos * refactor: rename mls publish to send and installation_id to installation_key * chore: gen protos * wip * Add more query methods * Add support for cursor based refresh state * Make compiler happy * Allow for different types of refresh_state * Streaming support * Add send trait * Fix docker-compose file * Remove comment * Fmt * Fix incorrect query * Remove log statements * Sleep longer to better handle races * Update gen-protos * Make flakey test less flakey * Add more streaming tests * Disable flakey test * Use latest uniffi * Switch to latest uniffi * Merge in latest changes * Move everything back to lib.rs * Move back to separate files * Try building in CI * Fix reference to dylib * Release swift bindings (#460) * Correct order in swiftlocal makefile * Added github action for adding zipped xcframework to github release on tag action * Run on branch commits instead of tags * Updated tag name to not begin with refs * Run swift local only needs to copy over source now * fix tag name, add license to release zip artifact * Add step for calculating checksum for release description * Fix SHA command and check LICENSE is copied as expected * Updated to only fire from manual workflow dispatch for now * Remove test branch from build action --------- Co-authored-by: Steven Normore <[email protected]> Co-authored-by: Cameron Voell <[email protected]> Co-authored-by: cameronvoell <[email protected]>
Added a GH action for adding swift bindings to a GH Release.
Adding the binary artifacts to a release would allow xmtp-ios to reference our libxmtp FFI bindings without needing to use libxmtp-swift as a "middle man" repo (release artifacts can be referenced directly from Swift Package Manager).It turned out that we can not get rid of thelibxmtp-swiftrepo because we still need theSourcefolder which is generated fromlibxmtp, and it is not possible to access that remotely from Swift Package Manager. However, if we hold on tolibxmtp-swift, publishing the XCFramework as a release artifact inlibxmtpdoes get us around having to usegit-lfsin ourlibxmtp-swiftwhich is important because it turns out Swift Package Manager does not work withgit-lfs(although Cocoa Pods does fine withgit-lfs, go figure!).A "pre-release" will be generated from this branch that will be tested against
xmtp-iosin order to validate that this strategy works for getting our static binarylibxmtpFFI intoxmtp-ios.The checksum in the Release description is used for specifying a binary target in our libxmtp-swift Package.swift file (for Swift Package Manager). See: https://github.com/xmtp/libxmtp-swift/pull/4/files#diff-f913940c58e8744a2af1c68b909bb6383e49007e6c5a12fb03104a9006ae677e
See Related PRs: