Hey all :wave: Do we have a multiplatform oss proj...

# multiplatform

[gammax]

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]

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

[Javier]

They are working together in merging both plugin into new one

[Javier]

https://github.com/gradle-nexus/publish-plugin

[Javier]

I am searching my previous setup with no 3rd plugins

[Javier]

but the last one I find is this https://github.com/JavierSegoviaCordoba/Resource/blob/0979f2e675b0b0682c57e70d41ad[…]4bdf96/buildSrc/src/main/kotlin/plugins/MavenPublish.gradle.kts

[Javier]

but java-library is not required and I was using dokka in the newer versions

[Robert Jaros]

https://github.com/reduxkotlin/redux-kotlin is published to central with maven-publish

[ian.shaun.thomas]

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]

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]

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]

@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]

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]

if you get that working, please, share the PR here 🙂

[mbonnin]

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

[mbonnin]

I think it's fine to have one repository per OS/job and then close them separately in OSS?

[mbonnin]

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]

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]

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]

@romainbsl why do you need 3 OS?

[Javier]

Is it no enough Windows + macOS?

[Javier]

or you are using three machines to improve the build time

[romainbsl]

we need to build on linux as well, at least for some libs as Kodein-DB that is compiling leveldb for every possible target

[romainbsl]

so, we build host only target for windows / linux, and everything else on MacOS.

[mbonnin]

@romainbsl you can put a comment in the OSS staging repository url, that'll help identifying the repositories

[mbonnin]

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]

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]

@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]

it should be possible in GitHub Actions

[Javier]

I don't know about other platforms

[Javier]

I will share the reply I get in a few minutes

[romainbsl]

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]

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

[mbonnin]

For lazy url computing, can you upvote https://github.com/gradle/gradle/issues/16205 ?

[romainbsl]

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]

$GITHUB_ACTION changes when you re-run I believe

[mbonnin]

The unique identifier (id) of the action.

Arg, maybe not...

[romainbsl]

there is a $JOB_ID I believe

[mbonnin]

But $JOB_ID would be per-OS?

[mbonnin]

Damn Github Actions yellsatsky

[romainbsl]

yep sorry >.<

[Javier]

https://github.community/t/share-environment-variables-across-multiple-runners/161008/2

[mbonnin]

So much yaml to read and make sense of... 😅

[Javier]

Should be great GitHub Actions get support for Kotlin scripts like YouTrack

[Javier]

I think yaml is not a good format for CICD

[Javier]

when you have a bit of logic it is very annoying to do simple things

[mbonnin]

maven {} actually supports lazy urls \o/

[mbonnin]

Opening a new staging repo becomes relatively easy: https://github.com/martinbonnin/vespene/commit/deefd80c08c29633a6d86b7e697b4353702f6c98

[louiscad]

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]

Why would you do that? So that you only have 1 repo?

[mbonnin]

(the implicit one?)

[louiscad]

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

[mbonnin]

Sure but you could also create a repo first and use that repoId in all subsequent jobs

[mbonnin]

That will result in one staging repo with all the artifacts

[louiscad]

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]

re-uploading will create a new one

[mbonnin]

Ah, I see it now, we need a per-run id to create a new one

[mbonnin]

Yeaaaa

[mbonnin]

Also, not sure sonatype will like overwriting files 🤔

[louiscad]

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

[mbonnin]

And then retrieve the biggest largest one?

[Javier]

I had problems overwriting files in nexus

[Javier]

in snapshot there is no problem

[louiscad]

@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]

snapshot repo doesnt need to be closed or signed

[Javier]

You can just upload a version

[Javier]

and reupload the same version one week later

[Javier]

but I am not sure at 100%, because sonatype was having overload when I had that problems

[Javier]

so maybe doing a new test is the way to go

[mbonnin]

snapshots repo will delete your artifacts "aftersometime"

[louiscad]

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]

@mbonnin that is the theory, I have snapshot there since... months

[Javier]

even maybe one year or more

[louiscad]

That is snapshots, not staging repository

[Javier]

literally: Thu Jun 25 210124 UTC 2020

[louiscad]

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]

I think using semantic version with nexus is what you want to "stable things" (not only stable releases, alphas, betas, EAPS, etc)

[Javier]

SNAPSHOTS are only for an easy way of testing purpose

[louiscad]

I don't want testing to lead to unreproducible builds

[louiscad]

Dogfood ≠ dog fool