https://kotlinlang.org logo
Join Slack
Powered by
I'm updating Confetti repo (<https://github.com/jo...
# touchlab-tools
j
I'm updating Confetti repo (https://github.com/joreilly/Confetti) to latest version of KMMBridge....I might be missing something obvious from docs but getting error now with the 2 lines commented out below....have these been replaced with something else?
Copy code
kmmbridge {
    frameworkName.set("ConfettiKit")
    mavenPublishArtifacts()
    //githubReleaseVersions()
    spm()
    //versionPrefix.set("0.8")
}
ah, I should probably have read https://kmmbridge.touchlab.co/docs/PORTING_0.3.x 🙂
👀 1
Copy code
An explicit setting of versionPrefix in the plugin config should be removed. By default, version is read from Gradle, and that is the version published. There is no concept of versionPrefix in the current build.
where exactly is this read from? 
version is read from Gradle
looks like you need to use 
timestampVersions
if you want KMMBridge to "increment" version each time?
getting a bit further but running in to following now (from https://github.com/joreilly/Confetti/actions/runs/8560540845/job/23459768015)
Copy code
- In plugin 'org.gradle.api.publish.maven.plugins.MavenPublishPlugin$Inject' type 'org.gradle.api.publish.maven.tasks.PublishToMavenRepository' property 'credentials.username' doesn't have a configured value.
    
    Reason: This property isn't marked as optional and no value has been configured.
    
    Possible solutions:
      1. Assign a value to 'credentials.username'.
      2. Mark property 'credentials.username' as optional.
ah, think that was only needed if publishing maven artifacts.....removed that and now getting https://github.com/joreilly/Confetti/actions/runs/8568451491/job/23482296959
k
You need to use the latest GitHub Actions workflow. It's a long story, but the KMMBridge Gradle plugin used to do way too much stuff. That included trying to set "version" while it was running, which should already be "set" at that point. The "new" version of KMMBridge is quite different. Paired with the updated GH workflow, it should function about the same, but trying to run the new version with either a custom GH workflow or the old one will be bad.
The version increment happens in the GH workflow now, basically. KMMBridge also (mostly) got out of the "git modification" business.
j
I thought I was using the new one
But will double check
k
I' just skimmed the thread. Will look at your workflow run
You are. Let me look...
j
I could very likely have missed something
just to confirm....should 
mavenPublishArtifacts
be necessary....if just publishing swift package?
k
Yes. It tells KMMBridge that you'll use a maven repo to publish. There's a warning in the log, but we should obviously just "fail":
Copy code
You must apply an artifact manager! Call `artifactManager.set(...)` or a configuration function like `mavenPublishArtifacts()` in your `kmmbridge` block.
j
a maven repo to publish the swift package?
k
Yep. We're only using it for the URL. Xcode doesn't actually use maven to access the artifact. https://github.com/touchlab/KMMBridgeSKIETemplate/commit/318cd25d69155064927f436c6633152af4bc6184
See 
remoteKotlinUrl
in the diff on the right.
j
ah, ok
k
See the "zip" at the bottom.
It's confusing, but there aren't many places to put files in GH for download that don't "blow up" your repo size. The only 2 that we've tried are attached to a release, which "worked" but was hacky in a number of ways. The other is GH packages, but it is very restrictive around options. You can't just "dump" a file in there. However, implementing the maven publisher means this also works with Artifactory, etc. You just have a more complex config, but all the same "publisher" implementation.
j
so I had originally included 
mavenPublishArtifacts
but was getting that 
property 'credentials.username' doesn't have a configured value.
error....was that related to something else?
k
addGithubPackagesRepository()
That sets up access to GH Packages
j
k
j
ah, but it has to be outside the 
kmmbridge
block?
k
Were you running publish locally? It needs to be in the GH workflow. That's where it gets access from. I don't know if it has to be outside of the block, TBH. Was just thinking about that.
I don't think it needs to be.
j
no, just running in GH workflow
k
Hmm. Not sure, then.
Anyway, try the PR I sent. See if that changes the situation.
👍 1
j
unrelated to this issue but the other thing I need to figure out is if any workarounds these days for adding repos in Xcode if they use git-lfs....might need to move the Packge.swift to another repo
k
It's probably easier to explain all this stuff on a call, but I'm about to just into a "meeting train"
j
I hear you had an earthquake in NY!?
k
The way KMMBridge publishing works is it creates a "build branch" and writes the Package.xml file to the root with the url, but in that branch only, creates a version tag, then deletes the branch. The 
Package.xmi
file is still there in the commit and tag, but not in 
main
or any other (visible) branch.
Now, if you have other stuff in your 
Package.xml
file and can't have the whole thing auto-gen, then it's more complicated, but I think doable.
However, getting back to the recent question I had, why are you publishing the XCFramework at all? It looks like the iOS code is in the repo. This is my main topic at KotlinConf, so I'm very curious 🙂
j
so...we're already sharing backend with other clients (e.g. the official AndroidMakers app uses the Confetti backend)
k
I hear you had an earthquake in NY!?
Yeah, I was on a call with one person in Europe, and another also in NY, and both NY folks were like "oh shit!" I've felt an earthquake here before, but not like that. Still, for a CA resident, it would've been a joke.
j
and idea was that we could potentially share the shared code so people could just skin it any way they wanted
particularly for iOS client with idea that as we know an iOS dev would be happier to just pull in a swift package to use
k
particularly for iOS client with idea that as we know an iOS dev would be happier to just pull in a swift package to use
"know" is a strong word. They can't debug anything, or (maybe) put in some log statements to see what's happening. I suspect an iOS dev interested enough in using a KMP-based core for a conf app might not entirely agree once they start trying to actually use it.
(I'm challenging the "know" part 🙂 , obviously)
That is certainly easier to start, but not after.
j
yeah, that's probably better way of putting it
depends on how much debugging they'd be expected to do I guess
k
Also, for the folks actually working on Confetti the app, does the publishing process get in the way of dev? The burden for a "published" SDK adds a lot to the dev workflow overhead. I guess the folks working on the Confetti app are doing local builds in dev?
j
yeah, exactly....all local in that case right now
k
So when do you actually "publish"?
j
still not sure exactly how/when this would happen....just looking atm at getting it setup
k
Ah, OK.
j
and also of course want as usual to try it out 😃
k
Well, I'm working on a "different thing", as mentioned. I'd be interested in trying that out with the Android Maker's app.
👍 1
j
maybe some additional secrets etc that need to be setup?
assume I don't need this any more btw?
k
Hold on. Was in meeting...
j
No rush at all
k
I suspect the env vars don't carry into the called workflow. The repsy config is what seems to be failing. The kmmbridge plugin adds the iOS artifact to all configured maven publishing plugins. I added an update that I think would work, if you wanted to keep that publishing.
j
ok, thanks....I'll try that
even though we're not using repsy any more.....think that had been needed in a previous version?
now getting following not sure why it's trying to push artifact there
Copy code
> Failed to publish publication 'KMMBridgeFramework' to repository 'GitHubPackages'
   > Could not PUT '<https://maven.pkg.github.com/joreilly/Confetti/Confetti/shared-kmmbridge/1.0/shared-kmmbridge-1.0.zip>'. Received status code 409 from server: Conflict
I don't have to use repsy if it makes things any easier
from SO anyway 
The 409 conflict is because you are publishing the same file name to the same path twice.
I'll take a look tomorrow and compare with other examples
going to try and omit the 
publishing
section in build file as seems defaults should work in that case....
k
Forgot to set version to `autoVersion`: https://github.com/joreilly/Confetti/pull/1243. It gets 409 because it was trying to push 1.0 again.
All of the artifacts are 
1.0
https://github.com/joreilly/Confetti/packages/2115001. They should start incrementing: 
0.9.0
, 
0.9.1
, 
0.9.2
, etc. From 
LIBRARY_VERSION=0.9
👍 1
j
k
Looks like GH is stuck on the link task
j
I've seen it take a long time on that for some reason
k
Still trying to publish to 1.0
Copy code
<https://maven.pkg.github.com/joreilly/Confetti/Confetti/shared-kmmbridge/1.0/shared-kmmbridge-1.0.zip>
That project/module version needs to be the auto-gen version.
You can delete the package there and it should finish publishing, but that'll only work once 🙂
j
got a new one at least after deleting that 🙂
Copy code
> Failed to publish publication 'KMMBridgeFramework' to repository 'maven'
   > Could not PUT '<https://repo.repsy.io/mvn/joreilly/confetti/Confetti/shared-kmmbridge/1.0/shared-kmmbridge-1.0.zip>'. Received status code 413 from server: Request Entity Too Large
I might have messed up some merges....going to do another run shortly
Doesn't seem to be updated 
Package.swift
but maybe this is one of changes from 0.3.x version I had before....
s
Is that because of this https://kotlinlang.slack.com/archives/CTJB58X7X/p1712333086437979?thread_ts=1712255313.950189&amp;cid=CTJB58X7X perhaps. The changed file only exists in that git tag, which is not really obvious when just looking at the repo in the main branch
👍 1
j
ah, probably the reason
see that version here
🥳 1
but run in to the issue again with git-lfs I think 😞
confirmed btw that this is part of code associated with that tag
Copy code
// swift-tools-version:5.3
import PackageDescription

// BEGIN KMMBRIDGE VARIABLES BLOCK (do not edit)
let remoteKotlinUrl = "<https://maven.pkg.github.com/joreilly/Confetti/Confetti/shared-kmmbridge/0.9.7/shared-kmmbridge-0.9.7.zip>"
let remoteKotlinChecksum = "ed0b6e9ae1a0018e41ead73d0036bd9f3e90adc34efd085a47a391c2f31d32f5"
let packageName = "ConfettiKit"
// END KMMBRIDGE BLOCK

let package = Package(
    name: packageName,
    platforms: [
        .iOS(.v13)
    ],
    products: [
        .library(
            name: packageName,
            targets: [packageName]
        ),
    ],
    targets: [
        .binaryTarget(
            name: packageName,
            url: remoteKotlinUrl,
            checksum: remoteKotlinChecksum
        )
        ,
    ]
)
this is a nice summary btw about git-lfs issue https://forums.swift.org/t/swiftpm-with-git-lfs/42396/13
k
GitHub packages requires Xcode auth, even for public repos. I assume because they want to put a small barrier to prevent people from simply using them as a big file host.
j
I've been adding other packages from github but I'll double check
fwiw did quick test in new project and was able to add https://github.com/rickclephas/KMP-NativeCoroutines swift package
but maybe difference in confetti because of access to 
<http://maven.pkg.github.com|maven.pkg.github.com>
k
Rick, library is all source code. The problem is accessing binary zip files. That’s what makes this so complicated. It’s also why you basically can’t use Amazon S3. S3 has no basic authentication option. By the way, I’m doing this on my phone with voice recognition in a very loud and windy place, so pardon the grammar issues.
j
it's doing very well in that case 🙂
and again no urgency at all for this
so fact that I can add for example https://github.com/joreilly/PeopleInSpacePackage is because binary is in repo directly...
k
Yeah, it’s on your local drive.
j
makes sense
k
for whatever reason, in their infinite wisdom, the xcode developers decided that the source access to get hub, and the binary access to get hub are entirely separate processes
• GitHub, obv
j
I updated 
~/.netrc
but still failing....but likely that git-lfs will cause issue anyway
I'll try another repo that doesn't have git-lfs
k
What’s your net RC config, minus the access token obviously?
I’ll try it when I get home. The Xcode config is very unforgiven, but I promise it works.
j
Screenshot 2024-04-06 at 17.40.14.png
k
Oh, I generally avoid git-lfs whenever possible. I don’t have much experience with it.
j
yeah, we have in project due to screenshot testing artifacts
so used following hack to work around that and now I think I'm at point where issue is with downloading package zip
Copy code
ln -s /opt/homebrew/bin/git-lfs /Applications/Xcode-15.2.0.app/Contents/Developer/usr/bin/git-lfs
I used following from those docs but maybe got something wrong....will double check now
Copy code
machine <http://maven.pkg.github.com|maven.pkg.github.com>
  login [your username]
  password [your PAT]
ah, are those square brackets needed?
k
brackets aren’t needed (I think). I’ll have to check when I get home.
j
ok, was issue with my token
so combination of that git-lfs hack and netrc and it worked
k
The whole thing is a huge pain. I don’t really have good place that you can push mine in every files and access them without a whole bunch of hassle. GitHub is free, but you still have to be authenticated. Obviously, free binary file hosting isn’t a good business model, so I haven’t found any.
*binary files
j
updated following project to use that version of package https://github.com/joreilly/ConfettiSwiftUISPM
35 Views
Open in Slack
PreviousNext
Powered by