https://kotlinlang.org logo
#multiplatform
Title
# multiplatform
g

gammax

02/15/2021, 10:39 AM
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 🙏
j

Javier

02/15/2021, 10:43 AM
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-pluginhttps://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
r

Robert Jaros

02/15/2021, 11:08 AM
https://github.com/reduxkotlin/redux-kotlin is published to central with
maven-publish
i

ian.shaun.thomas

02/15/2021, 2:00 PM
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
r

romainbsl

02/18/2021, 8:37 AM
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.
g

gammax

02/18/2021, 8:38 AM
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 🙂
j

Javier

02/18/2021, 8:41 AM
@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.
r

romainbsl

02/18/2021, 8:45 AM
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
j

Javier

02/18/2021, 8:53 AM
if you get that working, please, share the PR here 🙂
m

mbonnin

02/18/2021, 9:13 AM
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)
j

Javier

02/18/2021, 9:19 AM
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.
r

romainbsl

02/18/2021, 9:20 AM
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.
j

Javier

02/18/2021, 9:20 AM
@romainbsl why do you need 3 OS?
Is it no enough Windows + macOS?
or you are using three machines to improve the build time
r

romainbsl

02/18/2021, 9:22 AM
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.
m

mbonnin

02/18/2021, 9:23 AM
@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
r

romainbsl

02/18/2021, 9:27 AM
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 👍
m

mbonnin

02/18/2021, 9:29 AM
@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
j

Javier

02/18/2021, 9:32 AM
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
r

romainbsl

02/18/2021, 9:35 AM
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
m

mbonnin

02/18/2021, 9:36 AM
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 ?
r

romainbsl

02/18/2021, 9:41 AM
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?
m

mbonnin

02/18/2021, 9:45 AM
$GITHUB_ACTION changes when you re-run I believe
Copy code
The unique identifier (id) of the action.
Arg, maybe not...
r

romainbsl

02/18/2021, 10:16 AM
there is a
$JOB_ID
I believe
m

mbonnin

02/18/2021, 10:18 AM
But
$JOB_ID
would be per-OS?
Damn Github Actions yellsatsky
r

romainbsl

02/18/2021, 10:45 AM
yep sorry >.<
m

mbonnin

02/18/2021, 12:20 PM
So much yaml to read and make sense of... 😅
j

Javier

02/18/2021, 12:21 PM
Should be great GitHub Actions get support for Kotlin scripts like YouTrack
💯 1
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
m

mbonnin

02/18/2021, 2:12 PM
maven {}
actually supports lazy urls \o/
l

louiscad

02/18/2021, 2:55 PM
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?
m

mbonnin

02/18/2021, 2:56 PM
Why would you do that? So that you only have 1 repo?
(the implicit one?)
l

louiscad

02/18/2021, 2:58 PM
I'd do that so I get one staging repo with all of the artifacts, which means easier testing.
m

mbonnin

02/18/2021, 2:59 PM
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
l

louiscad

02/18/2021, 3:01 PM
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?
m

mbonnin

02/18/2021, 3:02 PM
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 🤔
l

louiscad

02/18/2021, 3:06 PM
Another thing we could do is simply generating a staging repo name from the timestamp of the beginning of the workflow
m

mbonnin

02/18/2021, 3:09 PM
And then retrieve the biggest largest one?
j

Javier

02/18/2021, 3:21 PM
I had problems overwriting files in nexus
in snapshot there is no problem
l

louiscad

02/18/2021, 3:21 PM
@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 ?
j

Javier

02/18/2021, 3:22 PM
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
m

mbonnin

02/18/2021, 3:24 PM
snapshots repo will delete your artifacts "aftersometime"
l

louiscad

02/18/2021, 3:24 PM
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.
👍 1
j

Javier

02/18/2021, 3:31 PM
@mbonnin that is the theory, I have snapshot there since... months
even maybe one year or more
l

louiscad

02/18/2021, 3:32 PM
That is snapshots, not staging repository
j

Javier

02/18/2021, 3:32 PM
literally: Thu Jun 25 210124 UTC 2020
l

louiscad

02/18/2021, 3:33 PM
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)
j

Javier

02/18/2021, 3:34 PM
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
l

louiscad

02/18/2021, 3:35 PM
I don't want testing to lead to unreproducible builds
Dogfood ≠ dog fool
3 Views