feat: add spm to deployment

[DominicGBauer]

Description

This adds creation of an xcframework.zip file which can be used with SPM. Currently SPM packages must be in xcframework or xcframework.zip format in order to be downloaded by users. This .zip file is then included in the release. We then use the https://github.com/peter-evans/repository-dispatch?tab=readme-ov-file GitHub action to create an spm-release event and include the release information in the payload. The event with the payload is handled by powersync-ja/powersync-sqlite-core-swift#1.

Work Done

1. Changed the build-pod.sh file to the more appropriately named build_xcframework.sh and moved it to the tool folder. It now also includes generating a zip version of the xcframework.
2. Adapted the release GitHub action workflow so that the xcframework.zip is included in the release upload.
3. Also included a release event that is sent to other repo with relevant information which will be used to update the Package.swift file in that repo.

[rkistner]

How about creating a dedicated repo where we publish the swift package, instead of pushing to master on this repo?

[DominicGBauer]

I think that could work although it may mean some duplication and more effort. We would need to investigate a way to download the newly created xcframework.zip generated from this repo and add it to a release in that repo. We would also need to be sure to keep the versions in check. I'm not sure we could avoid needing to do a release on this repo followed by a manual release on that repo. It does look like we could do something similar to this https://github.com/realm/SwiftLint/blob/0a1ee180da3787418fbcd3e85013b4ac04e48c72/.github/workflows/release.yml#L18-L27.

If you have a security concern about the current approach we could use https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication the GitHub token and only scope it to that particular job to reduce our risk.

[rkistner]

My concerns are less about security, more about the workflow.

Currently our release process is roughly:

1. Create PR including the version bumps.
2. Create release tag.
3. gh workflow run release --ref <tag>

If I understand correctly how SPM works, releases are resolved using the tag. That would mean the xcframework would have to be built before the tag, potentially something like this:

1. Create PR including the version bumps.
2. gh workflow run create-xcframework --ref <branch>
   a. Builds the xcframework
   b. Updates the current branch with the checksum
3. Create release tag.
4. gh workflow run release --ref <tag>

But now we run into difficulty upload of the xcframework - it can't be uploaded to a draft release, since the tag for the release doesn't exist yet. Basically a circular dependency issue. Some projects appear to avoid that by placing the xcframework directly in the repo source, but that can quickly bloat the repo.

A further general concern here is that SPM always has to download the entire repo - including all the source files etc that it doesn't need.

---

My idea of a separate SPM repo is that it can be fully automated using our current release process. There shouldn't be any duplication required - everything can be managed from this repo.

I imagine something like this:

1. Create PR including the version bumps.
2. Create release tag.
3. gh workflow run release --ref <tag>
   a. Creates draft release
   b. Build and upload xcframework
   c. Calculate checksums and generate Package.swift
   d. Commit, tag and push Package.swift to the powersync-sqlite-core-swift repo

The new powersync-sqlite-core-swift repo only needs the Package.swift file. The xcframework URL can point to the release in this repo. You can think of that repo as the equivalent of a published NPM package, rather than the source we use to publish it.

[DominicGBauer]

I'm not 100% sure how we can test this without a release?

[rkistner]

You can create a "temp" release using something like this:

git tag -am v0.3.0-testspm1 v0.3.0-testspm1
git push --tags
gh workflow run release --ref v0.3.0-testspm1

Then just delete the tag and the draft release afterwards.