Sonatype snapshots failing again

[cpovirk]

They were fixed in #1832 back in October, but they started failing again in late June. Here are the last successful run and the first failing run. The first failure came after #1933, but the failure at least naively seems unrelated to that:

Error: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:3.1.2:deploy (default-deploy) on project auto-common: Failed to deploy artifacts: Could not transfer artifact com.google.auto:auto-common:pom:HEAD-20250701.023018-657 from/to sonatype-nexus-snapshots (https://oss.sonatype.org/content/repositories/snapshots/): status code: 403, reason phrase: Forbidden (403) -> [Help 1]

Granted, who knows, it could be that the new maven-invoker-plugin is trying to deploy itself when it shouldn't or something.

[cpovirk]

Ah, and our snapshots are still using maven-deploy-plugin.

I recently discovered that Truth snapshots were likewise using maven-deploy-plugin (not the central-publishing-maven-plugin that I'd expected). When I switched to the new plugin, I ran into a succession of issues (google/truth#1586, google/truth#1587, google/truth#1596). At the moment, Truth is broken with a 401 instead of the 403 that Auto is seeing. The Google AI Overview tells me that 401 is "cannot validate identity" and 403 is "your identity lacks permissions." If that's what Sonatype's telling us, then I wonder if we're seeing some combination of using credentials from the wrong system (old vs. new) and lacking permission to deploy to the old anymore. (But then why would Truth have been able to deploy to the old when I last had it set up that way recently, and why would Guava be able to do so even now?) I'll try plugging in permissions for Truth according to https://central.sonatype.org/publish/generate-portal-token/. I don't see anything relevant-looking in Sonatype's documentation of snapshots, since our projects have all had snapshots enabled for a while.

Anyway, I have a mega-change pending to get all our projects off maven-deploy-plugin. That might not fix anything, but it should at least move us to consistently use the system that we want to be using. (That said, maven-deploy-plugin is probably safe-ish here if we're excited to keep two different plugins working, one for snapshots and one for full releases: Sonatype documents: "Because publishing -SNAPSHOT releases does not perform validation on the component(s), a mvn deploy-compatible API was chosen for maximum ecosystem compatibility.") And if anyone actually cares about snapshots (most likely for Guava?), then I hope that that person lets us know.

[cpovirk]

I took the values from my ~/.m2/settings.xml (with which I have performed successful releases recently, including for Truth) and plugged them into the Truth secrets, and then I reran the job. It still failed.

But when I run JAVA_HOME=$HOME/openjdk-11.0.16 mvn clean deploy -DskipTests=true for Truth locally, it succeeds.

I don't know what to make of that combination of facts.

[cpovirk]

Ah! If I modify my ~/.m2/settings.xml to contain only one <server> block, the one for sonatype-nexus-snapshots, then my local Truth run reproduces the 401. So it must be that what we actually need is either sonatype-nexus-staging, central, or sonatype-central-staging.

I wonder if the from/to central part of the error message means that it's central. But now I know how to find out!

[cpovirk]

Yes, it's central.

edit: so something like:

<settings>
  <servers>
    <server>
      <id>central</id>
      <username>a-value-from-the-central-site</username>
      <password>another-value-from-the-central-site</password>
    </server>
  </servers>
</settings>

...where "the Central site" is the one that https://central.sonatype.org/publish/generate-portal-token/ points you toward.