Thread
#multiplatform
    gammax

    gammax

    1 year ago
    Hey all 👋 Do we have a multiplatform oss project that is publishing to
    mavenCentral
    and using the
    maven-publish
    plugin (no 3rd parties)? If yes don’t you mind linking 🙏
    Javier

    Javier

    1 year ago
    I had one, but
    maven-publish
    is not working very good with mavenCentral because it generates multiple staging repositories, we should have two repos, one for general artifacts + windows and another for apple artifacts. But I was getting 5 or 6 (but I think this is not caused by KMP itself). So I moved to: • https://github.com/marcphilipp/nexus-publish-plugin https://github.com/Codearte/gradle-nexus-staging-plugin
    They are working together in merging both plugin into new one
    I am searching my previous setup with no 3rd plugins
    but
    java-library
    is not required and I was using dokka in the newer versions
    Robert Jaros

    Robert Jaros

    1 year ago
    https://github.com/reduxkotlin/redux-kotlin is published to central with
    maven-publish
    ian.shaun.thomas

    ian.shaun.thomas

    1 year ago
    This is a little funky as I wanted JVM to be a dependency of Android so JVM libs depending on this can be used in Android without hassle but it is all maven-publish https://github.com/ToxicBakery/Arbor/blob/master/common/build.gradle#L216
    romainbsl

    romainbsl

    1 year ago
    Hi @gammax. Did you end up with a satisfying solution? @Javier did you use https://github.com/gradle-nexus/publish-plugin for KMP across platforms (linux/macos/windows)? My guess is that it would end by creating, at least, a staging repo by OS when running on CI.
    gammax

    gammax

    1 year ago
    Not yet, I still haven’t managed to get back to this. But I’m planning to send out a PR for #koin between today and tomorrow. Ideally someone could also chime in if interested in contributing 🙂
    Javier

    Javier

    1 year ago
    @romainbsl at this moment is not possible to avoid the creation of multiple repos with that plugin (I did a feature request). @mbonnin library can let you to get this. Should be great if it was integrated in some way in the nexus plugin to achieve that.
    romainbsl

    romainbsl

    1 year ago
    yep, I am considering building everything on each OS, put the artifacts in a cache, and upload everything once. This would be more convenient to us because we are managing multiple libraries on the same repo for #kodein
    Javier

    Javier

    1 year ago
    if you get that working, please, share the PR here 🙂
    mbonnin

    mbonnin

    1 year ago
    I think what we want is avoid implicitely created staging repos. I just made a patch to support this in vespene: https://github.com/martinbonnin/vespene/commit/8cb910fc82e195424826d9a59576094be16c7704#diff-95efc5ecd7a769d42177ff6[…]aa1a317a1607e3a2c5a6368c47R23
    I think it's fine to have one repository per OS/job and then close them separately in OSS?
    Ultimately, I think what we really want, is a lazy
    MavenArtifactRepository.url
    that only creates the staging repo when publishing (and not when configuring the gradle build)
    Javier

    Javier

    1 year ago
    for me I don't care about how many repositories, just closing them via gradle commands. But because I haven't a lot of releases of a lot of artifacts/repos, but I can understand it can be better only one repo for a specific release to avoid mixing different projects, etc.
    romainbsl

    romainbsl

    1 year ago
    It's fine, but as we are managing, for now, 5 libraries, when upgrading Kotlin we would end up with 15 staging repos (5*3), if 1 one as failed it becomes cumbersome to find what are staging repos to drop etc.
    Javier

    Javier

    1 year ago
    @romainbsl why do you need 3 OS?
    Is it no enough Windows + macOS?
    or you are using three machines to improve the build time
    romainbsl

    romainbsl

    1 year ago
    we need to build on linux as well, at least for some libs as Kodein-DB that is compiling leveldb for every possible target
    so, we build host only target for windows / linux, and everything else on MacOS.
    mbonnin

    mbonnin

    1 year ago
    @romainbsl you can put a comment in the OSS staging repository url, that'll help identifying the repositories
    Ultimately, if https://github.community/t/ability-to-rerun-just-a-single-job-in-a-workflow/17234/5 ends up being implemented, having more granular publishing would be easier to manage as you'd only re-run the one job that failed
    romainbsl

    romainbsl

    1 year ago
    this would be sooo useful! But, yes explicitly create the staging repo first, is my go to. It's even better if I can explicitly identify that repo when publishing, thx for the tip 👍
    mbonnin

    mbonnin

    1 year ago
    @Javier and I discussed the possibility of creating a staging repo in a first required job. Then the question becomes how you'd transfer the stagingRepositoryId in subsequent jobs
    Javier

    Javier

    1 year ago
    it should be possible in GitHub Actions
    I don't know about other platforms
    I will share the reply I get in a few minutes
    romainbsl

    romainbsl

    1 year ago
    With Github Actions you can share cache / artifacts. For example, you can write the repositoryId in a file attach it to your job, and then download and read the file in subsequent jobs
    mbonnin

    mbonnin

    1 year ago
    That would work. Another solution I was thinking about would be to put the
    $GITHUB_ACTION
    in the staging repository description and then look it up directly from the Sonatype API in subsequent jobs
    For lazy url computing, can you upvote https://github.com/gradle/gradle/issues/16205 ?
    romainbsl

    romainbsl

    1 year ago
    yes this could work, but what happen if you re-run a failed action, you may have 2 staging repo with the same
    $GITHUB_ACTION
    in the description?
    mbonnin

    mbonnin

    1 year ago
    $GITHUB_ACTION changes when you re-run I believe
    The unique identifier (id) of the action.
    Arg, maybe not...
    romainbsl

    romainbsl

    1 year ago
    there is a
    $JOB_ID
    I believe
    mbonnin

    mbonnin

    1 year ago
    But
    $JOB_ID
    would be per-OS?
    Damn Github Actions :yellsatsky:
    romainbsl

    romainbsl

    1 year ago
    yep sorry >.<
    mbonnin

    mbonnin

    1 year ago
    So much yaml to read and make sense of... 😅
    Javier

    Javier

    1 year ago
    Should be great GitHub Actions get support for Kotlin scripts like YouTrack
    I think yaml is not a good format for CICD
    when you have a bit of logic it is very annoying to do simple things
    mbonnin

    mbonnin

    1 year ago
    maven {}
    actually supports lazy urls \o/
    louiscad

    louiscad

    1 year ago
    If the GitHub action is not resettable, maybe another solution is to delete any existing staging repo at the start of the workflow, before letting the uploading jobs run?
    mbonnin

    mbonnin

    1 year ago
    Why would you do that? So that you only have 1 repo?
    (the implicit one?)
    louiscad

    louiscad

    1 year ago
    I'd do that so I get one staging repo with all of the artifacts, which means easier testing.
    mbonnin

    mbonnin

    1 year ago
    Sure but you could also create a repo first and use that repoId in all subsequent jobs
    That will result in one staging repo with all the artifacts
    louiscad

    louiscad

    1 year ago
    Yep, but I was talking about the error case when you need to re-run the workflow. Or maybe it's a non issue and reuploading just overwrites?
    mbonnin

    mbonnin

    1 year ago
    re-uploading will create a new one
    Ah, I see it now, we need a per-run id to create a new one
    Yeaaaa
    Also, not sure sonatype will like overwriting files 🤔
    louiscad

    louiscad

    1 year ago
    Another thing we could do is simply generating a staging repo name from the timestamp of the beginning of the workflow
    mbonnin

    mbonnin

    1 year ago
    And then retrieve the biggest largest one?
    Javier

    Javier

    1 year ago
    I had problems overwriting files in nexus
    in snapshot there is no problem
    louiscad

    louiscad

    1 year ago
    @Javier What's the difference betweem the two, and which one is relevant in the case of uploading to a staging repo for Maven Central ?
    Javier

    Javier

    1 year ago
    snapshot repo doesnt need to be closed or signed
    You can just upload a version
    and reupload the same version one week later
    but I am not sure at 100%, because sonatype was having overload when I had that problems
    so maybe doing a new test is the way to go
    mbonnin

    mbonnin

    1 year ago
    snapshots repo will delete your artifacts "aftersometime"
    louiscad

    louiscad

    1 year ago
    And then retrieve the biggest largest one?
    @mbonnin If you do it all in one workflow, you'll not need that since you already have it from the workflow first step.
    Javier

    Javier

    1 year ago
    @mbonnin that is the theory, I have snapshot there since... months
    even maybe one year or more
    louiscad

    louiscad

    1 year ago
    That is snapshots, not staging repository
    Javier

    Javier

    1 year ago
    literally: Thu Jun 25 21:01:24 UTC 2020
    louiscad

    louiscad

    1 year ago
    I personally don't use them (snapshots) because that makes the builds unreproducible. I prefer dev versions (I use bintray for that… 🙃 😅 until I can no longer)
    Javier

    Javier

    1 year ago
    I think using semantic version with nexus is what you want to "stable things" (not only stable releases, alphas, betas, EAPS, etc)
    SNAPSHOTS are only for an easy way of testing purpose
    louiscad

    louiscad

    1 year ago
    I don't want testing to lead to unreproducible builds
    Dogfood ≠ dog fool