Circling back/extending a previous conversation .....

# touchlab-tools

[Bradleycorn]

Circling back/extending a previous conversation ... My teams have been using KmmBridge to share our KMP code as a library for our android and ios apps. We have a development process setup that mostly works well for us. There's one piece that I wish we could do better, but I'm not sure how/what to do ...

When working on a feature for our apps, a dev team might make several commits to a feature branch in the KMP repo. For the devs, this is no problem. We use the Local Dev Flow . They have the appropriate feature branch checked out, and can do their dev on the feature. The issue is with our automated builds for our QA process. We use Github Actions to do a build of the app when a PR is merged to a feature branch. When that happens, the app needs to know what "version" of the kmp library to use. To this point, we've just been publishing a new version with every piece of work on the feature so that there's a new version number for the automated build to pull. But that's really not a great solution long term. We're publishing tons of versions, many of them with "partially working" features. We may want to expose the published library to some third party partners, and at that point we definitely don't want to expose "half baked" versions. I've been trying to think of a way to get those automated feature builds of the apps to work without having to publish a new version of the kmp library. Curious if anyone else has run into and solved this issue?

[Bradleycorn]

A few solutions we've thought of:
1. Use GitPortal and build sources instead of using binaries - That might be where we end up. I've done a POC with gitportal in unidirectional mode. There's a little bit of developer flow complexity to manage, but it may work out. We can build sources in our apps and also publish a binary for other (3rd party partners) to pull into their apps.
2. Use the same "local dev flow" for the automated feature builds - basically setup the same branch name on our apps and the kmp repo for the feature, and use github actions to pull the appropriate branch from the kmp repo and use it to do the build in the same "local dev flow" that the developers use. That could work, but we're not a huge fan of "the app repos and the kmp repo MUST use the same branch name". That's ok most of the time, but we don't like it as a hard and fast rule. Wish there was a way to make it more flexible.
3. For features, publish semantically versioned "WIP" or "alpha" builds - That would probably work, but still results in publishing versions that aren't "fully baked".
4. Use some complex githuhb actions workflows - There's probably several variations of this where we setup workflows that publish "temporary tags", or delete and re-create a tag each time a piece of work is pushed to the kmp repo. It just feels brittle, and hard to maintain. In general, actions workflows are a thing where you set it up, and then it runs and you don't think about it anymore. When you have to come back later and make changes, it's hard to remember everything that's going on. I prefer to try and keep complexity out of actions workflows as much as possible.

[kpgalligan]

Ah, well, this is exactly (I think) what I was getting at in the other conversations about a KMMBridge flow that approximates what you might get with gitportal, and avoiding the versioned library problem. In summary, instead of publishing a binary to a specific version number, you publish a binary attached to a branch. SPM can use branches instead of semver versions. You just need to configure everything to wire up correctly. With our updated method of debugging from binaries in Xcode, the branch version code is also debuggable.

[kpgalligan]

The work to do this is mostly (maybe entirely?) functional, and the blog post drafts were in-flight. My focus got shifted, so I don't entirely remember off-hand where it was at. I'd need to dig.

[kpgalligan]

This is directly focused on PR build support. Not sure how it would work with external, but I'm guessing that's more of a messaging issue than a technical one. However, I had configured this specifically for the repo structure of publishing from an Android repo rather than a three-repo structure. Ironically, SPM is better able to handle that out of the box. SPM can point at a dependency with either a version, a branch, or (I think) a specific commit. Gradle isn't so flexible. However, Gradle can take something like "1.3.2-my-pr-branch" as a version. You'd need to configure your publishing to support that, though.

[Bradleycorn]

n summary, instead of publishing a binary to a specific version number, you publish a binary attached to a branch.

ah, that's an interesting approach. It kind of marries the local dev flow (point it at a branch [ref], and build that branch) with the "published flow" (point at a release/tag [ref], and get a binary from it).

I've been trying to come up with a decent way using the local dev flow to specify which kmp repo branch to pull (store it some file that gets checked into the repo or something), but haven't come up with any great solutions. But telling spm to look at a specific branch is a pretty good way to handle it. We're still on cocoapods at the moment, but we're going to move to spm soon.