Hey there I am trying to release a Swift Package u...

# touchlab-tools

[Jan Starczewski]

Hey there I am trying to release a Swift Package using KMMBridge using not a template but integrating the plugin and tooling into project I work on basically I did

kmmbridge {
    mavenPublishArtifacts()
    spm()
    addGithubPackagesRepository()
}

gradle properties

LIBRARY_VERSION=0.5
GROUP=com.aiocare.bluetooth

and added a workflow like in the tmplate

name: Publish iOS BLE package
on:
  workflow_dispatch:
    branches:
      - develop
jobs:
  call-kmmbridge-publish:
    permissions:
      contents: write
      packages: write
    uses: touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuildautoversion.yml@v1.1
    with:
      jvmVersion: 17
      versionBaseProperty: LIBRARY_VERSION
      publishTask: kmmBridgePublish publishKotlinMultiplatformPublicationToGitHubPackagesRepository

The problem that I face is on the CI, basically

Execution failed for task ':bluetooth:publishKMMBridgeFrameworkPublicationToGitHubPackagesRepository'.
> Failed to publish publication 'KMMBridgeFramework' to repository 'GitHubPackages'
   > Could not PUT '<https://maven.pkg.github.com/aiocare/aiocare-sdk/com/aiocare/bluetooth/bluetooth-kmmbridge/0.5.1/bluetooth-kmmbridge-0.5.1.zip>'. Received status code 401 from server: Unauthorized

I feel like I am missing something regarding the CI configuration, but I went through the docs and seems like things are set properly
Is there something obvious that I am missing here? More info in the thread

[Jan Starczewski]

The thing is that I see some artifacts being published though (with xcframework) but due tu the failure here I cannot proceed with the workflow to add Package.swift etc. and unfortunately I cannot use the package in xcode side 😞

[Jan Starczewski]

My CI config is based on default values

[Filip Dolník]

Hi! By I see some artifacts being published though (with xcframework) do you mean that you can download the xcframework from this URL <https://maven.pkg.github.com/aiocare/aiocare-sdk/com/aiocare/bluetooth/bluetooth-kmmbridge/0.5.1/bluetooth-kmmbridge-0.5.1.zip> after logging in?

[Jan Starczewski]

yes exactly, but the workflow fails and the Package.swift is not added (but when I did this manually aka added the Package.swift and also config in my netrc) I was able to use the package in the XCode project, but I would like to do it with the workflow instead

[Jan Starczewski]

I also remember (can do it once again soon) that there is also a task something like that

:bluetooth:publishKMMBridgeFrameworkPublicationToGitHubPackages2Repository

(With number 2 in it) and it succeeds

[Filip Dolník]

What version of KMMBridge do you have?

[Jan Starczewski]

0.5.2

[Filip Dolník]

And the issue happens only in CI or also locally (when running locally you need to pass additional arguments as described here: https://kmmbridge.touchlab.co/docs/general/CONFIGURATION_OVERVIEW#optional-gradle-parameters)

[Jan Starczewski]

I also had this issue locally passing the parameters

[Filip Dolník]

I assume that the Gradle property LIBRARY_VERSION is used to configure the project.version property right?

[Jan Starczewski]

yes in my case is set to 0.5

[Jan Starczewski]

but also I have a version set in my build.gradle.kts file that was 0.5.1

[Jan Starczewski]

so on CI they were matching

[Filip Dolník]

Let’s try incrementing the version. Maybe we get a different error for the first run and we will also see if it uploads the partial artifact again

[Jan Starczewski]

will do and I will let you know

[Jan Starczewski]

@Filip Dolník unfortunately I was not able to deploy it with version bump and to proceed with the workflow as I was hitting 401 every time. A friend of mine also has the same issue in another project. I will dig into it and see if Skie template works for me, sorry for late replay. Basically the packages lands somehow on registry with ‘publishKMMBridgeFrameworkPublicationToGithubPackages2Repository’ and publishKMMBridgeFrameworkPublicationToGithubPackagesRepository’ fails for me still ;(

[Filip Dolník]

Hm, maybe @kpgalligan will know what the problem might be.

[kpgalligan]

It'll be extremely difficult to help without access to the repo. If you're not using the GitHub actions workflow we've set up, you'll be missing pieces. For the 401, are you pushing to a different repo? Essentially, is aiocare/aiocare-sdk the same repo as where you have the :bluetooth module? Also, if you're directly setting version anywhere in Gradle, as it seems you are from the discussion above about 0.5.1, you'll run into issues eventually.

[Jan Starczewski]

Yes, that’s the same repo, and I am setting the version in Gradle as well but I kind of played with it so the versions in gradle were always matching with tag on the repo (build by LIBRARY_VERSION) in my configuration. I will remove usage of gradle’s version property and try again as it seems the LIBRARY_VERSION is used in other places and that’s probably gonna fix the issue. I thought gradle’s version wasn not the issue as one of the uploads was able to succeed and the other was not. Thank you Filip and Kevin for the answers, I will work on that more and let you know.

[kpgalligan]

The complication with our GitHub actions workflow is that it also tries to automatically number versions for dev builds.

[kpgalligan]

val autoVersion = project.property(
    if (project.hasProperty("AUTO_VERSION")) {
        "AUTO_VERSION"
    } else {
        "LIBRARY_VERSION"
    }
) as String

subprojects {
    val GROUP: String by project
    group = GROUP
    version = autoVersion
}

[kpgalligan]

https://github.com/touchlab/KMMBridgeSKIETemplate/blob/main/build.gradle.kts#L13C1-L25C2

[kpgalligan]

KMMBridge itself just takes the Gradle version, so if you set that and there's already a version deployed, it'll fail.

[kpgalligan]

This is all confusing for everybody, so we're doing an updated version that just uses GH releases, and skips the "autoversion". Also, this flow would only support SPM, which is mostly what people want (KMMBridge would still support CocoaPods, but CocoaPods config is much more complex).

[kpgalligan]

Work in progress (and no docs yet) https://github.com/touchlab/KMMBridge/blob/kpg/kxcbridge/.github/workflows/spmbuildpublish.yml

[kpgalligan]

So, for a build, you'd need to bump the version, but that's a lot simpler to understand than the autoversion thing.

[kpgalligan]

XCFramework zip would get deployed to the release in GitHub rather than using GitHub Packages and maven. Example attached. Of course, the GH Packages option would still be there, but for teams only pushing XCFrameworks for SPM, this is significantly less complicated and less likely to run into issues.

[Eirik Vale Aase]

Oh, this looks really nice 🚀