I have a multiplatform library (<https://github.co...
# multiplatform
p
I have a multiplatform library (https://github.com/krzema12/snakeyaml-engine-kmp) that I currently release from my local machine (MacBook). Even though it can release most of the targets, I realize I don't release e.g. Windows-specific targets. That's why I want to move the release workflow to CI. My CI tool of choice is GitHub Actions. The idea for the library is to publish it for as many targets as possible. I know that to achieve it, until cross-compilation isn't possible, I need to run the release task on 2 or 3 different runners (linux, macos, windows). Question: is there a recommended way of releasing a multiplatform library, showing how to configure the jobs so that the publish desired targets? In https://kotlinlang.org/docs/multiplatform-publish-lib.html#host-requirements I think there are two contradicting points: "Publish only from an Apple host when your project targets Apple operating systems." and "Publish all artifacts from one host only to avoid duplicating publications in the repository. Maven Central, for example, explicitly forbids duplicate publications and fails the process." - what about Windows targets? I think the problem of releasing a multiplatform library deserves clear docs with recipes how to do it correctly for major CI services, or maybe even some reusable blocks (GitHub Actions actions or e.g. CircleCI orbs)
CC @Adam S @Oleg Smirnov
a
I realize I don't release e.g. Windows-specific targets
A Macbook can build all Kotlin targets, so something else is going wrong
"Except for Apple platform targets, Kotlin/Native supports cross-compilation, allowing any host to produce needed artifacts."
p
just double checked, we do have
snakeyaml-engine-kmp-mingwx64
in https://repo1.maven.org/maven2/it/krzeminski/ also for the newest version 3.0.1, so I think my post was premature 🙂 so it's enough to configure a job that runs on a Mac!
o
Hi, @Piotr Krzemiński. Do you need any help with this workflow for publication from GitHub?
p
@Oleg Smirnov thanks, I think I know how to proceed: • switch to the Gradle plugin that handles auto-closing in Sonatype • Create the actual workflow, easy because we clarified here that just one job running on macos is enough If you have some time, contributions are always welcome, otherwise I'll probably get to it sooner than later 😊 although for now it's not that painful because we release the library pretty rarely