David
11/14/2024, 9:15 PMkpgalligan
11/14/2024, 9:30 PMDavid
11/14/2024, 9:39 PMDavid
11/14/2024, 9:40 PMkpgalligan
11/14/2024, 10:03 PMupdate-release-tag
(params) step to specify the target repo, and configure deploy keys. I don't remember off-hand if there were any other issues.David
11/15/2024, 12:13 AMkpgalligan
11/15/2024, 3:18 AMpublishAndroidDebugPublicationToGitHubPackagesRepository
the Android publishing command doesn't have the GitHub Packages repo defined. The docs need a bit of a reorg as that part is buried a bit: https://touchlab.co/kmmbridge/artifacts/mavenrepoartifacts#github-packages.David
11/15/2024, 3:40 AMkpgalligan
11/15/2024, 3:47 AMpublishKotlinMultiplatformPublicationToGitHubPackagesRepository publishAndroidDebugPublicationToGitHubPackagesRepository publishAndroidReleasePublicationToGitHubPackagesRepository
kpgalligan
11/15/2024, 3:48 AMpublish
. However, if that specific task is failing, that presumably means the GitHub Packages repo isn't set up, so Gradle won't have anywhere to publish to.David
11/15/2024, 3:59 AMDavid
11/15/2024, 4:02 AMkpgalligan
11/15/2024, 4:07 AM"presumably means the GitHub Packages repo isn't set up"KMMBridge has nothing to do with Gradle and Android publishing. The sample template has Android publishing configured, but only because that's what somebody using the sample would likely want.
addGithubPackagesRepository()
exists as a convenience function to set up the publishing target Maven repo. If that's confusing, then you can try setting up your publishing Maven repo manually.
If Android publishing with Gradle is confusing, that's a whole different topic.kpgalligan
11/15/2024, 4:10 AMpublishAndroidDebugPublication
- publish the android debug build
• ToGitHubPackagesRepository
- to the GitHub Packages repository
If the task doesn't exist, then that repo isn't configured.kpgalligan
11/15/2024, 4:10 AMkpgalligan
11/15/2024, 4:12 AMDavid
11/15/2024, 10:15 AMDavid
11/20/2024, 2:22 PMDavid
11/20/2024, 2:24 PMkpgalligan
11/20/2024, 2:43 PMI was able to publish now in a separate repo, I can forward you the minor needed changes once I'm done if you wishI'm curious how you push
Package.swift
to your external repo by way of a minor change, unless by the context of the following message you mean "maven repo"David
11/20/2024, 2:49 PM"Package.swift
to your external repo" you mean in the tag, right?David
11/20/2024, 2:53 PMkpgalligan
11/21/2024, 4:19 PMkpgalligan
11/21/2024, 4:20 PMkpgalligan
11/21/2024, 4:21 PMDavid
11/21/2024, 4:26 PMDavid
11/21/2024, 4:27 PMkpgalligan
11/21/2024, 4:29 PMWould be nice if we could optionally push the unziped content to the distribution repo main branch and then create the tagdefinitely out of scope for KMMBridge. Certainly in the near term. That's a very different process, and as mentioned, you'll run out of releases pretty quickly because the repo size will get quite large.
kpgalligan
11/21/2024, 4:30 PMDavid
11/21/2024, 4:30 PMkpgalligan
11/22/2024, 4:27 PMI mean you build freshly each time, what grows in size?The repo. Each fresh build lives in the repo. You don't see it, but it exists. If your XCFramework zip is 900k, which seems rather small, but OK, then uncompressed, it's, say 4m. If it's a year from now and you've done 25 point releases, your "small" dependency will be a 100m git repo. Something like that anyway. Having said that, in your case, write a build script that does some git tricks. Build the framework, pull the public as an alternate remote, create a worktree, copy your built framework into the worktree, commit and push. See this for ideas on how that would work: https://github.com/touchlab/ga-push-remote-swift-package/blob/main/src/main.ts#L46. KMMBridge itself is just a different use case than yours.
David
11/22/2024, 9:28 PMDavid
11/22/2024, 9:33 PMkpgalligan
11/22/2024, 9:40 PMDavid
11/22/2024, 9:42 PM