-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: maven kotlin multiplatform support #412
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The craft codebase uses semicolons, can we follow the same style?
src/targets/maven.ts
Outdated
if (existsSync(join(distDir, `${moduleName.toLowerCase()}.klib`))) { | ||
return `${moduleName}.klib`; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the file isn't accessible (e.g. it doesn't exist), the .jar
filename will be returned. I don't know if the .jar
file exists for kotlin, or what the consequences are of uploading it instead of the .klib
. If a required file for a release doesn't exist, we should fail the release.
Another thing to consider is how easy it'd be to debug a failing release. A message like "hey, I can't find xxx file" is more helpful than "hey, I'm uploading the files and can't read yyy file, which isn't related to the release at all".
An alternative approach is to update the target's config to keep track of what we are releasing (android? kotlin?). If we know that, we could return directly the .klib
filename, and let the upload fail if it can't read the file (which automatically produces a more helpful failure message). This is what currently happens with the .jar
file (no disk operations happen in this method).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kotlin Multiplatform needs to upload multiple artifacts, you upload either a .jar
or a.klib
or .aar
in case of Android. so if it's not an android artifact then if .klib
is not there then it must be a .jar
. So it shouldn't fail if it doesn't find a .klib
.
Since only Apple targets (ios, macos, etc...) are packaged as .klib
, I can add a target config like you said to keep track of those so I don't have to search for it's existence. However, I would still need to search for the existence of *.metadata
and *-all.jar
in getFilesForMavenPomDist
as they have to be added and they don't exist for every artifact (only the root artifact needs all.jar
and only apple artifacts have metadata.jar
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess what I can do is create a target config for kotlin-multiplatform
or something like that to keep the uploadPomDistribution
separated and only add those files if it's a kotlin-multiplatform
artifact. that way it doesn't interfere with the way it has been before I added the changes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks much better!
Also -- don't forget to add documentation for this new config in the README
.
@buenaflor did you try to call |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests currently only cover config loading. Put simply, what this PR introduces is spawning a process with a list of arguments executed under a certain condition (when we make a kotlin multiplatform release, run gpg blahblahblah
). Can we verify that the process is spawned, when it should and with the expected arguments?
@iker-barriocanal what do you think is still missing for this PR? just tests from your latest comment or some other comments need to be addressed? |
@romtsn I think only tests are missing (verifying the temporary folder as Manoel suggests may be one of them). That said, I'm not blocking the PR. I don't know if @asottile-sentry has other thoughts too. |
Making it a draft since it's not fully tested yet. |
I added a fix so that the published artifacts are correct and signed. I generated the artifacts manually & locally by calling the gpg publish commands as they were produced by Example output of a specific file:
I attached a file with all the generated gpg publish commands for doing it locally for the latest KMP build: kmp local publish via gpg sign deploy.txt |
LGTM from my side but I'd let the owners of this repo approve it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This introduces some additions to be able to support a Kotlin Multiplatform publish.
Additional artifacts include:
*.klib, *-all.jar, *-metadata.jar, *.module
.Example artifacts of Kermit:
For context: for a KMP publish all platforms need to be published and the root artifact contains metadata, see: getsentry/sentry-kotlin-multiplatform#37 (comment)
The generated gpg command example:
root artifact:
ios artifact: