Implement release process in fastlane

[crazytonyli]

We need a special release process for the Swift package. Because we can't publish a new release after creating a tag like other libraries. We need to package the Rust library into xcframework prior to creating a tag.

Package.swift uses the Rust library via a local xcframework, which is not included in the git repo and is only produced by running make xcframework locally. That works fine during development. But once the Swift package is released, SPM will need to checkout a specific version git tag whose Package.swift should not refer to a local xcframework because SPM can't run the make command for us.

In order for SPM to work out of the box, we'll need to pre-built the xcframework before creating a git tag. Here are the detailed process:

1. Build xcframework
2. Update Package.swift to fetch xcframework from a GitHub release assert URL (which isn't valid yet).
3. Push the changes to GitHub.
4. Create a GitHub release from the new commit.
5. Upload the built xcframework to the new GitHub release.

This PR implements these steps in fastlane: bundle exec fastlane release version:<new-version-number>. Please note, publishing a new version of Android library is not implemented at the moment. @oguzkocer I may need you to help fill in the blank here (see the fastlane release lane).

I also added a new release pipeline to CI, so that we can publish new releases via CI. Here is a test run to publish a new version 0.0.1. The build failed because the GitHub token doesn't have permission to create a tag. This new pipeline is not included in this PR. We can sort it out later if needed.

Test Instructions

If you want to test publishing new releases without pushing them into this repository, you can fork this repo into your own account and tests with your own repo. Once the repo is forked, update GITHUB_REPO and GIT_REMOTE_NAME accordingly. Run bundle exec fastlane release version:0.0.1.

Or, you can just test with this repo with the same command without changing any code. Remember to delete the new tags and releases after tests are completed.

[oguzkocer]

This PR implements these steps in fastlane: bundle exec fastlane release version:<new-version-number>. Please note, publishing a new version of Android library is not implemented at the moment. @oguzkocer I may need you to help fill in the blank here (see the fastlane release lane).

@crazytonyli We don't need to use fastlane to publish the Android artifacts. We have a custom Gradle plugin for it that we use for all our projects.

[crazytonyli]

@oguzkocer If I understand it correctly, that plugin is called via gradle command inside a "build tags" CI step. Since we have to have a special release process here to create a tag for us, I wonder if we should just call gradle from the fastlane file? Adding a CI stpe to publish Android artifacts certainly would work, but I thought it might be nice to have all release steps done in one place, rather than half in fastlane (creating a tag and Swift things) and the other half in a standalone CI step (Android things).

[oguzkocer]

I am not sure if Android publishing would even work the way we want using fastlane, but even if it did, I really don't like that idea. We don't use fastlane anywhere else in the Android library ecosystem and adding a wrapper here would break that with no additional value - in fact, it'll just add another abstraction. It's worth keeping in mind that it's not possible - or rather heavily discouraged - to publish Android libraries from our local environments, so it's only CI that we need to worry about.

We have a a8c-ci-toolkit-buildkite-plugin script that passes everything our plugin needs and we just need to run a simple command like this and the plugin will do everything else for us - which btw is already set up and ready to go.

I don't usually share strong opinions, but let's please not overcomplicate things and follow the same approach every other Android library uses.

[crazytonyli]

I totally overlooked publishing Swift and Android in one step wouldn't even work, because we don't have a mac agent that has Android tooling installed. So we'll have to release them separately.

[jkmassel]

This generally looks solid – to ensure we haven't missed anything, could you run it and tag a test release that we can validate?

[crazytonyli]

@jkmassel Absolutely. I'll make some pipeline changes, so that we can publish both Swift and Kotline libraries in one release. Regarding validating the release, we can validate the released Kotlin libraries in an empty Android project. But we won't be able to use the Swift package until this repository becomes public (due to the xcframework URL).

[oguzkocer]

@jkmassel Absolutely. I'll make some pipeline changes, so that we can publish both Swift and Kotline libraries in one release.

As previously mentioned, Kotlin & Android modules get published for every PR, every commit in trunk and every tag. There is nothing extra we need to do "to release" it. The only caveat to be aware of is that if you create a tag, it'll get published to S3 and a new version with that tag name can not be published again. So, if you use something like 0.1 for your test, we have to manually clean it up.

Regarding validating the release, we can validate the released Kotlin libraries in an empty Android project.

This is also done for Android artifacts here.

[crazytonyli]

@oguzkocer Nice. I didn't notice that those steps were already added to the pipeline 👍