https://kotlinlang.org
Join Slack
Is it possible to use KMMBridge with JDK 17 ? With AGP 8 projects have to move to that
# touchlab-tools
j
Is it possible to use KMMBridge with JDK 17 ? With AGP 8 projects have to move to that
👀 1
r
Should be, though we haven't tested extensively. If you're using our Github Actions workflow, you can pass 
jvmVersion
to control this in CI.
j
this is what we're using
Copy code
name: KMMBridge Publish Release
on: workflow_dispatch

jobs:
  call-kmmbridge-publish:
    uses: touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuild.yml@v0.8
r
yeah so try something like
Copy code
uses: ...
with:
  jvmVersion: 17
j
cool, thanks...will try that
Maybe still some issue with my setup but can create an issue if it helps
r
Sorry, I just lost track of this. Looks like we're passing an arg that isn't needed and went away in jdk17. Give this commit a try and if it works I'll merge and tag it as 0.8.1 
uses: touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuild.yml@a8bdf519fd761715b9c77cee38bb1545f29bf942
j
Is there way to test this locally....I've been running as part of GH action
r
I don't, but even if you test locally it still would want to upload to the same place so I don't think it would buy you much. You can temporarily set a lower version if you're really worried about something weird happening.
j
"Give this commit a try and if it works I'll merge and tag it as 0.8.1" Was just wondering how I'd verify if this works?
r
Do a publish with it and verify that it succeeds
j
You mean once 0.8.1 is there?
or was suggestion to build it locally with the commit you mentioned and somehow use that version?
ah, sorry, I misunderstood
r
You can point your build script directly at that sha using the syntax above
(it's actually a decent security practice to point directly at the commit hash anyway, because a malicious action could retag a version to a different commit without you realizing it)
j
Basic question but can I run that action in a branch? Just so that I don't have to merge the PR with this change
r
yeah, if you're running it from a workflow-dispatch trigger there should be a dropdown to select a branch
j
hmm, could be something on my side but getting issue with the 
jvmVersion
after updating to use that https://github.com/joreilly/Confetti/actions/runs/4756301825
Copy code
The workflow is not valid. .github/workflows/kmmbridgepnblish.yml (Line: 8, Col: 19): Invalid input, jvmVersion is not defined in the referenced workflow.
this is workflow I have now
Copy code
name: KMMBridge Publish Release
on: workflow_dispatch

jobs:
  call-kmmbridge-publish:
    uses: touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuild.yml@a8bdf519fd761715b9c77cee38bb1545f29bf942
    with:
      jvmVersion: 17
Hmm, I'm probably missing something obvious but still can't figure out why it's complaining
@russhwolf are there any examples out there using 
jvmVersion
.....I'm assuming I have some small syntax issues (didn't realise until now just how much I hated yaml 🙂 )
r
Looks like I pointed you to the wrong commit. Try 
2e121ace461e0004eb079926c1f6e74afaee3e3d
instead
sorry about that
j
np, looks like it's making more progress now https://github.com/joreilly/Confetti/actions/runs/4759065341
now getting
Copy code
Task 'kmmBridgePublish' not found in root project 'Confetti' and its subprojects.
r
ugh that's annoying. Usually that means you're missing ENABLE_PUBLISHING=true but I can see that in your output
I wonder if argument passing works differently in gradle 8 somewhow
Give this a try (switching up how we pass gradle properties) 
b795422fddc0bbedd1239857aa46c0d9520889c2
j
seems to be failing on same issue
r
ok I'm going to have to dig more, then. There's something behaving differently then it used to (probably due to java 17 or gradle 8, but not sure which) and we need to understand it better
j
Hi @russhwolf, just in case there's any workaround since for this?
r
Sorry, haven't had a chance to dig in yet. I'll see if I can find time this week.
Finally took a look (from the speaker room at Droidcon SF where I'm supposed to be finishing slides 😬). Looks like the issue was some missing config that I'm embarrassed to say I didn't catch (in addition to the original issue that the kmmbridge workflow wasn't working in java 17). Here's a PR that bumps the workflow to a newly-published compatible version and adds the missing config: https://github.com/joreilly/Confetti/pull/749 Last fall you were using our github release config to host artifacts, but we've since moved our recommended default to use github packages. At some point you removed the line 
githubReleaseArtifacts()
but didn't replace it with anything, so the plugin didn't have anywhere to push to. Because it didn't see an artifact manager anymore, it wouldn't configure the 
kmmBridgePublish
task.
j
Yay, thanks for that @russhwolf!
Best of luck with talk! Looks like @cafonsomota will be on in same room as you later in day.....his talk covers some of the Android Auto work he did in Confetti!
r
Oh cool! I didn't realize anyone from the team was here.
oh oops looks like it failed due to branch protection. One fix is to switch from 
faktorybuild.yml
to 
faktorybuildbranches.yml
. This will publish Package.swift updates to a separate branch. It'll be tagged so you can find it from the github UI, and Xcode will know how to find it and pick it up, but you won't see the most up-to-date version info in the package.swift on main anymore. If you'd rather keep things in main, it's probably also possible to configure the github actions runner to override the branch protection, but I don't know how to do that off-hand.
j
I disabled that for now as test and confirmed action worked then. However, when I try to add package in XCode I get this....anyway, I'll try and take closer look at weekend....could likely be some issue in my setup
r
Probably need to configure auth on your local machine. Some details here https://kmmbridge.touchlab.co/docs/DEFAULT_GITHUB_FLOW/#ios-dev-machine-config
j
I had this working before but maybe github token or something has expired....will take a look later (adding as Swift Package btw)
yep
hmm, still getting that error in XCode.....presumably some issue in my setup there still
if someone has change be great if they could try to add that package (from https://github.com/joreilly/Confetti)
hmm, might be related to following (we are using git-lfs in that repo) https://github.com/apple/swift-package-manager/issues/5351
r
What permissions do you have on that token? Will need read:packages at least, and maybe also repo.
j
yeah, I think I have all the permissions needed.....I suspect it's something to do with fact that repository uses git-lfs
I had had this working before but we hadn't git-lfs at that point
r
Ok. I don't have much experience with lfs
j
If you have a chance can you add package to XCode there and see if it works
r
Yeah I can take a look in a bit
Seems to work fine for me. If I add it to the Confetti Xcode project I can't build because it conflicts with the local copy, but it pulls fine and builds in a fresh Xcode project.
j
ok, thanks for trying....will dig a bit deeper here
Hmm, still not having much luck....tried token with everything enabled as test and get same error. Also tried an old package I had (in different repo) and that worked (https://github.com/joreilly/ConfettiSwiftPackage) ...something perhaps with using github packages now
I'm creating new XCode project and trying to add it to that
one difference between those repos is that the 
ConfettiSwiftPackage
one is picking up xcframework locally whereas the KMMBridge based one is using following....though error above seems to indicate it had issue before that checking out from repo
Copy code
let remoteKotlinUrl = "<https://maven.pkg.github.com/joreilly/Confetti/Confetti/shared-kmmbridge/0.8.3/shared-kmmbridge-0.8.3.zip>"
if I try to open 
<https://maven.pkg.github.com/joreilly/Confetti/Confetti/shared-kmmbridge/0.8.3/shared-kmmbridge-0.8.3.zip>
I'm prompted for username/password.....is expectation that XCode can retrieve this?
or presumably it can use token for this as well
hmm, ok, if I use my username and the token I created then I can download that zip file manually from here....so token ok for that anyway
anyway, given it works for you there it must be some issue with setup here
btw do you know of another repo that has used KMMBridge to create/publish swift package like this....can try adding package from that as test.
r
Xcode will authenticate to that url assuming you have the token in your netrc or keychain per the doc I linked above.
Away from my laptop now but I can push the test project I used later
j
btw noticed from following: "If your repo is public, you should be able to access the binary that you just published without any auth configuration" https://touchlab.co/quick-start-with-kmmbridge-1-hour-tutorial/
fwiw I get error as well trying to install package from https://github.com/touchlab/KMMBridgeSampleKotlin
get this....and then in errors I see (which seems to indicate some permissions issue) "failed downloading 'https://maven.pkg.github.com/touchlab/KMMBridgeSampleKotlin/KMMBridgeSampleKotlin/shared-kmmbridge/0.8.4/shared-kmmbridge-0.8.4.zip' which is required by binary target 'shared': badResponseStatusCode(401)"
r
What do you have in your netrc?
j
Do I need to update that for public repo?
r
Not 100% sure but I think so. The note in the 1 hour tutorial might be outdated because originally it was pushing a binary to github releases instead of github packages
We're more often doing this in closed-source contexts where auth is expected anyway
j
I also see from https://kmmbridge.touchlab.co/docs/spm/IOS_SPM "When you acces repos in GitHub with Xcode, you need to authenticate to GitHub. That isn't enough to access private GitHub release artifacts. You also need to add 
~/.netrc
or Mac Keychain Access authentication info."
r
yeah. do that part
j
that sounds though like only needed for private repos?
r
for releases it was only needed for private. For packages it's always needed I tihnk
j
as you say I guess this is mostly targeted at closed source environments.....I think this would be a lot to ask user if you wanted them to consume package from public repo
r
yeah. Can also plug in other artifact hosting. github packages is just an easy default in a lot of cases
This will let you publish artifacts to any maven repo of your choice: https://kmmbridge.touchlab.co/docs/artifacts/MAVEN_REPO_ARTIFACTS
j
ah, cool....will take a look at that
should 
./gradlew kmmBridgePublish
still work (from that page)?
r
Yeah. That task will call into whatever artifact manager you have configured, and if you use the maven artifact manager it will send things to whatever maven repo you have configured
j
hmm, it's not finding that for some reason
r
If you're trying to call it locally, you'll need to set the gradle property 
ENABLE_PUBLISHING=true
j
see it now, thanks
k, next thing I'm seeing is following....is this gitub repo that this is part of?
Copy code
KMMBridge Github operations need a repo param or property GITHUB_REPO
I guess this is probably designed to work primarily in CI env
found some more info here about it
r
yeah, for local you'll need to pass GITHUB_REPO which will look like 
joreilly/confetti
and GITHUB_PUBLISH_TOKEN which gets generated automatically in actions
for running locally, you can generate a personal access token. It will need repo write permission to be able to push the package.swift file update, and package write permission only if your publishing to github packages
I usually use a classic token because I understand the permission model better there
j
yeah, that's one I've been using here.....enabled write packages and seems to work now
r
cool. If you move to a different maven repo with public read access you can drop the write packages permission
j
and just confirmed I'm able to add package in XCode now
r
Very cool!
j
will look next at hooking that up to run on CI
r
You should be able to still use the same GitHub actions setup
j
ah, cool....will try that
just need to add my repo.repsy.io credentials as secrets in gh
should I still need 
addGithubPackagesRepository
?
r
No, drop that
That configurrs the github packages maven but you're not using that anymore
j
should something like this not work?
Copy code
call-kmmbridge-publish:
    uses: touchlab/KMMBridgeGithubWorkflow/.github/workflows/faktorybuild.yml@v0.9
    with:
      jvmVersion: 17
    env:
      MAVEN_USERNAME: ${{ secrets.REPSY_USERNAME }}
      MAVEN_PASSWORD: ${{ secrets.REPSY_PASSWORD }}
getting 
Unexpected value 'env'
but I could be missing something basic
r
Try doing env at top-level instead
j
get `No steps defined in 
steps
and no workflow called in 
uses
for the following jobs: env` then
hmm, actually probably should be further "up"
r
Yeah I mean at the very top
Next to permissions
j
r
Hm. Looks like it's still not reading the env correctly
j
yeah.....anyway, will do some more google'ing later....this has to be common enough thing to do
r
If doing things via env variables isn't working, you can try gradle properties instead. We have a passthrough to forward gradle properties to the kmmBridgePublish call in the workflow, so you could add something like
Copy code
secrets:
  gradle_params: -PMAVEN_USER=... -PMAVEN_PASSWORD=...
(where secrets is at the same level as inputs) and then update your build.gradle to do
Copy code
credentials {
  username = properties["MAVEN_USER"]
  password = properties["MAVEN_PASSWORD"]
}
j
where would those gradle params be set?
so they'd get picked up in CI.....still as secrets?
I see the docs include this....is idea that if you setup those up as secrets in CI this will pick them up as well?
Copy code
publishing {
    // Externally set these values. Generally ~/.gradle/gradle.properties or CI Secrets
    val publishUsername: String by project
    val publishPassword: String by project
    repositories {
        maven {
            url = uri("<https://someservice/path/to/repo>")
            credentials {
                username = publishUsername
                password = publishPassword
            }
        }
    }
}
r
I don't remember all the details about secrets vs inputs for actions, but that's just where we have things configured to inject gradle properties. It should mean it does stuff like masking them in the console output. Secrets won't get automatically picked up but you would reference the project secrets in the ...'s from my snippet above
j
cool, will give it a go tomorrow when I'm more awake 😉
Just to close loop on this..... @mbonnin realised we only really needed to use 
kmmBridgePublish
for what we were doing so updated to use that https://github.com/joreilly/Confetti/blob/main/.github/workflows/publish-kmmbridge.yml
actually might not need to use 
GITHUB_PUBLISH_TOKEN
etc that we're still passing that.....
or maybe that's still needed....
had thought maybe it was just for publishing github package
r
The package file update will still need github access, but it will only need commit access, not package write
custom script should be fine. The extra things we have that you're not using are mostly just for auth to things you don't need
j
btw @mbonnin found reason why env values weren't being propagated
Copy code
Any environment variables set in an env context defined at the workflow level in the caller workflow are not propagated to the called workflow. For more information, see "Variables" and "Contexts."
r
oh right, you probably needed to send it via the netrc parameters
140 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by