Hello, We’ve been using KMMBridge for almost a ye...

# touchlab-tools

[Mohammed Akram Hussain]

Hello,

We’ve been using KMMBridge for almost a year now and are currently on 0.3.x versions and would like to migrate to 0.5.1. We have a self hosted GitLab setup for our CI and publish KMP binaries on another repo on GitHub. We were reliant on GitRemoteVersionWriter for this and is removed in the latest versions of KMMBridge.

I have been looking into the GitHub workflow and these actions touchlab/autoversion-tagmarker, touchlab/autoversion-buildbranch, touchlab/autoversion-finishrelease, and touchlab/autoversion-tagmarker.

I’m not sure which one of these are relevant to us and they’re in typescript which makes things a bit complex for me to understand and get the picture.

Any help in migration and pointing out which actions are relevant to us will be really helpful.

Thanks!

[kpgalligan]

0.5.x is a significant change from 0.3.x. The major changes involved moving most of the git operations to CI instead of doing them in the plugin, and this also meant moving most version calculation operations out of the plugin as well.

[kpgalligan]

The actions you've linked to perform various tasks. This blog post explains each: https://touchlab.co/kmmbridge-without-github?ti=91641D87271A419A8F9EF6047D

[kpgalligan]

GitRemoteVersionWriter was removed, as well as the VersionWriter concept in general. You would need to write something that can publish a version to GitHub from GitLab. I have no experience with GitLab CI, so not sure how straightforward that would be.

[kpgalligan]

In summary, the new CI workflow does the following:
• Check out the code
• Calculate the new version
• Add a git tag as a temporary version marker. This is mostly for CocoaPods, as we need to publish the binary before trying to publish to the CocoaPods repo, which runs a test to build the pod which can fail. In a fail case, if we tried to run the same build version again, the publish would fail, so we keep a "marker" and if found, we just use the next number
• Create a build-only branch (you don't need this if you don't want it)
• Run the build/publish
• "Finish" the release (push the actual git version tag)
• Clean up the "marker" tag(s)
• Delete the build branch. The commit still exists, so if you want to try out that code, you can make a new branch from the commit, but otherwise we just use it to host the modified Package.swift file