Hi all. I am updating to the latest KmmBridge (fro...

# touchlab-tools

[Bradleycorn]

Hi all. I am updating to the latest KmmBridge (from 0.5.5), and I'm getting the dreaded "*Task 'kmmBridgePublish' not found in root project"* error when running a build via CI (Github Actions). First, yes, I am passing the ENABLE_PUBLISHING=true property when running the kmmBridgePublish task. Hoping someone can point me in the right direction ....
More details in the 🧵

[Bradleycorn]

The exact command I'm running is:

./gradlew  kmmBridgePublish \ 
 -PKMP_BUILD_MODE=library \
 -PENABLE_PUBLISHING=true \
 -PAUTO_VERSION=0.0.25 \            
 -PGITHUB_PUBLISH_TOKEN=*** \ 
 -PGITHUB_REPO=myorg/myrepo \          
 -PNATIVE_BUILD_TYPE=RELEASE \
 -PGITHUB_ARTIFACT_RELEASE_ID=218670995 \
 --no-daemon --info --stacktrace

My setup is fairly standard, except that I have a custom gradle plugin that I apply to my KMP modules and the kmmbridge configurations are in there. But the configs themselves are basic/standard. I have also confirmed (printing to the console) that my plugin is being properly applied.

specifically, my kmmbridge config that gets applied to my umbrella (allShared) module is:

fun Project.configureKmmBridge(extension: KmmBridgeExtension) = extension.apply {
    println("Configuring KmmBridge")
    gitHubReleaseArtifacts()
    spm()
    cocoapods("[e-mail]:myorg/MyPodSPecs.git")
}

the above function gets called from my custom plugin like so:

import co.touchlab.kmmbridge.KmmBridgeExtension
import com.myorg.myrepo.buildLogic.configureKmmBridge

class UmbrellaModuleConventionPlugin: Plugin<Project> {
    override fun apply(target: Project) = with(target) {
        with(pluginManager) {
            apply(kmpLibs.plugin("touchlab.kmmbridge.github"))
            apply(kmpLibs.plugin("kotlin.cocoapods"))
        }
        extensions.configure<KotlinMultiplatformExtension>(::configureCocoapods)
        extensions.configure<KmmBridgeExtension>(::configureKmmBridge)
    }
}

[Bradleycorn]

This type of setup (the custom plugin approach) has been working fine with kmmbridge 0.5.5, so I don't think there's anything wrong there. I feel like it has to be something more specific that I'm doing with the kmmbridge configuration itself.

[kpgalligan]

I find deep Gradle config to be rather tricky to manage if I'm doing it, so it's kind of extra hard to do with small bits, if you know what I mean. But. not found in root project would be thing to check #1. Probably not related, but if the root project is including kmmbridge but not apply false? Otherwise, there's some other reason the publishing section isn't being run because config drops out before it gets there, but isn't reporting that anywhere. If not that, then the Gradle params from the command aren't making their way to whatever needs them.

[Bradleycorn]

yeah gradle config is quite confusing. I have several modules and try to move the common config boilerplate in all of them to a single plugin that I can apply to all and just manage it in one spot. I'll try moving the kmmbridge config back into the main module config files and see where that gets me. It's weird though cause as I mentioned it has been working for over a year, I'm just now getting around to upgrading kmmbridge to the latest version. I checked the root config file and it's not applying the plugin.

[kpgalligan]

I know it's a huge pain, but if this persists and you know what you want the config to look like, a minimal repro would help.

[Bradleycorn]

OMG 🤦 . It was the gradlew command in the workflow yml. Something was messed up with it being split over multiple lines. I condensed it all down onto a single line and it works. I probably had some trailing whitespace after the \ on one of the lines or something.

[kpgalligan]

CI. It'll get ya.

[kpgalligan]

I'm really glad you found that, btw. Sometimes these things are hours of starting at code that has nothing to do with the situation. Of course, an error message that explained the situation would help. We don't register those tasks if you're not in CI mode, but we could register tripwire versions that would throw an error saying why they're not registered.

[Bradleycorn]

Yeah, especially Github Actions CI, where there's no real way to test it or run it locally. I was certain that I was passing the ENABLE_PUBLISHING=true flag, so I spent most of my time trying to figure out where my gradle configuration was wrong. But it turns out, the gradle config was fine.

Another idea ... include a "dry run" or "validation" task that just verifies that the configuration is setup correctly. Devs could run that task locally to be sure everything is setup correctly before having CI run it.