I am still getting the same error via Github actio...
# library-development
a
I am still getting the same error via Github actions when publishing my KMP library and I cannot figure this out. I was able to publish this morning but I got the same error in the evening. Any ideas?
Copy code
> Failed to close staging repository, server at <https://ossrh-staging-api.central.sonatype.com/service/local/> responded with status code 400, body: Failed to process request: No objects found in the repository
yml:
Copy code
name: Release

on:
  release:
    types: [published]

permissions:
  contents: read

jobs:
  publish:
    runs-on: ubuntu-latest
    environment: maven-central
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.release.tag_name }}
      - uses: gradle/actions/wrapper-validation@v3
      - uses: actions/setup-java@v4
        with:
          distribution: temurin
          java-version: 17

      - uses: actions/cache@v4
        with:
          path: |
            ~/.gradle/caches
            ~/.gradle/wrapper
          key: gradle-${{ runner.os }}-${{ hashFiles('**/gradle-wrapper.properties', '**/*.gradle*', '**/gradle.properties') }}
          restore-keys: |
            gradle-${{ runner.os }}-

      - name: Compile
        run: ./gradlew --no-daemon --console=plain assemble

      - name: Detekt
        run: ./gradlew --no-daemon --console=plain detekt

      - name: Test
        run: ./gradlew --no-daemon --console=plain jvmTest

      - name: Publish to Maven Central
        env:
          OSSRH_USERNAME: ${{ secrets.OSSRH_USERNAME }}
          OSSRH_PASSWORD: ${{ secrets.OSSRH_PASSWORD }}
          SONATYPE_STAGING_PROFILE_ID: ${{ secrets.SONATYPE_STAGING_PROFILE_ID }}
          SIGNING_KEY_ID: ${{ secrets.SIGNING_KEY_ID }}
          SIGNING_KEY: ${{ secrets.SIGNING_KEY }}
          SIGNING_PASSWORD: ${{ secrets.SIGNING_PASSWORD }}
        run: ./gradlew --no-daemon --console=plain publishToSonatype --max-workers 1 closeAndReleaseSonatypeStagingRepository
m
Not really the answer to your question but migrate to the central portal api?
Maybe you'll get a better error there?
The whole staging repo thing is deprecated IIUC
a
Where do I find that? I am clueless towards what I am doing here
m
Are you using vanniktech to publish?
a
I dont think so. I used the same setup since a few years ago and never investigated/touched it
m
That looks more like you're using this one? https://github.com/gradle-nexus/publish-plugin/
a
is vanniktech the "go to" ?
yeah the gradle nexus seems to be the one im using
m
Vanniktech is good, does a lot of things for you. I also maintain a lower-level one (https://github.com/GradleUp/nmcp/)
So long term you're probably better migrating to one of these
a
isnt there an 'official' one from maven central?
m
Sadly not
But I mean short term it's weird that it's not working. The "old" way is deprecated but should still be around so maybe you can save the migration
If you have access to the UI, you can double check your staging repo, see if anything is inside
You may also try to run your build with
-i
, IIRC it shows the files being uploaded
a
i dont think the issue is with the plugin. I never had this error while publishing locally. been trying to automate it these days and the error I get started from the CI
good ideas. will check
👍 1
c
i dont think the issue is with the plugin. I never had this error while publishing locally.
Publishing locally is very different than publishing to a repository. Local publishing is largely copying files around, whereas publishing to a repository is HTTP/API calls and all the semantics around that.
v
The whole staging repo thing is deprecated IIUC
Not really, unless that was changed. The old infrastructure was switched off, and the publishing portal go the ability to continue use the old way to stay using the established plugins and workflows. I'm not aware those are "deprecated". They recommend not to use it as they want their new publishing portal stuff being used instead of the standard Gradle way. But this compatibility layer is afaik not deprecated and hopefully also will not.
@Chris Lee I think he meant he called the MC publishing task locally and now tries to automate it in GHA 🙂
☝️ 1
👌 1
I don't see any deprecation note on https://central.sonatype.org/publish/publish-portal-ossrh-staging-api/ that documents this compatibility layer from a quick skim-over. :-)
m
Is there even a UI showing the staging repos if you're using the old API?
v
So yeah, I'd also recommend looking at the open repos using web ui to check whether something is awkward currently
I hope so, didn't publish since they switched off the old infra
m
I'm not sure you can
It really feels like a last minute add-on to avoid breaking everyone's workflow.
No objects found in the repository
That sounds like a task dependency/aggregation was not setup properly and
closeAndReleaseSonatypeStagingRepository
just creates an empty staging repo that is closed without even uploading files
c
iirc there were known race conditions with setting up/closing those staging repositories; those were largely addressed in the Vanniktech plugin.
r
I agree migrating to central portal api is the way to go. The ossrh compatibility layer is not stable when publishing large projects.
b
Two Important things to know, GitHub actions changes its IP frequently, even during the same step, but the ossrh-staging-api relies on you publishing from the same IP. Unfortunately that means part of the deployment can easily be left out and without any warning. It took a lot of troubleshooting to figure out that's what was going on for me 😅 I haven't used the nexus plugin so can't say for sure it's the same issue, but that's my experience with gradle's maven-publish plugin. Switching once more to using the vanniktech plugin was pretty straightforward, and it's configured almost exactly the same, plus it takes care of signing/snapshots automatically. The staging API is probably fine of your CI has a static IP, but definitely not for GitHub's free runners
m
I think the point of opening/closing the repo using the nexus plugin is that it uses a specific per-staging-repo url so there's no automatic per IP attribution
👍 1
a
wasnt expecting this much discussion over this. thank you so much for the detailed infos folks