search

google / truth

Fluent assertions for Java and Android
https://truth.dev/
Apache License 2.0
2.73k stars 260 forks source link

Sonatype and Javadoc snapshots both failing since recently #1343

Closed cpovirk closed 2 months ago

cpovirk commented 2 months ago

I assume that Sonatype is the same issue as https://github.com/google/auto/issues/1832.

Javadoc appears to have broken with the maven-javadoc-plugin update of https://github.com/google/truth/pull/1333.

cpovirk commented 2 months ago

Hmm, user tokens are now "Only available in Sonatype Nexus Repository Pro." That explains why I don't see them in the Sonatype UI anymore.

As for why Sonatype deploys broke in the first place: I think I was missing the significance of some of the announcement:

To configure a publisher’s plugin authentication you would need to update your plugin settings to use a user token instead of the Nexus UI username and password login.

Presumably we were previously using a "normal" username+password pair, but now we need to use a user token.

But, as noted above, user tokens recently became restricted to Pro users. (Guava looks to still be able to deploy snapshots, I guess because my existing user token wasn't invalidated by that policy change? I don't think I saved that token anywhere, though, so I can't supply it for our other projects.)

I may just disable Sonatype snapshot publishing, as I'm not sure that anyone actually cares about it. We can view Truth (and Auto) as a test case for what happens. (I mean, they've already been acting as a test case for about a month now, and that's on top of when Guava snapshots were broken, albeit only for a few days....)

I'll be interested to see what the Javadoc issue is about, given that Truth and Auto appear to have started having Javadoc problems as of upgrades to different plugins....

cpovirk commented 2 months ago

Wait, if I follow the https://oss.sonatype.org/index.html#profile;User%20Token link that I got from the previous time I looked up the token, I can't see my token. And I thought I had even tried closing and reopening the Profile tab and still couldn't see it. But now that I do that again (after logging back in, so maybe that mattered?), I can see it. I'll try to update Truth to use it now.

cpovirk commented 2 months ago

Oh, and it looks like I had the old value in my .m2/settings.xml all along... :) I guess that makes sense if all pushes need to use the token now. (So does everyone need a Pro account to publish? If so, does Google have one?)

Anyway, I've updated Truth to use it, and I've updated Auto, as well. (One of the updates initially failed for whatever reason....) That should leave only the Javadoc problem.

(Somewhere in this process, I learned that there exists google.oss.sonatype.org, which might be mostly/exclusively for Cloud? I had wondered if maybe we needed to use that to get the Pro access or something. I'm not sure what's up, but it's something that we could look into in the future if we have more trouble.)

cpovirk commented 2 months ago

I'll be interested to see what the Javadoc issue is about, given that Truth and Auto appear to have started having Javadoc problems as of upgrades to different plugins....

I got to wondering if it was an upgrade in the version of Javadoc itself: I think we just get whatever "version 11" is the current default for GitHub, so it may be upgraded without any action on our part.

But no, the last success and the first failure both report using "Java 11.0.24+8 (Zulu) from https://cdn.azul.com/zulu/bin/zulu11.74.15-ca-jdk11.0.24-linux_x64.tar.gz." (Even the next-to-last success used the same thing, so I don't think we're seeing a delayed effect, either.)

cpovirk commented 2 months ago

Hmm, could it be that the Javadoc is failing because the Sonatype push is failing? I ran the Javadoc script locally with JDK11, and it worked fine. Then I ran mvn clean and tried it again, and it failed. So maybe it's relying on the Sonatype step to succeed, since that step performs mvn deploy? In particular, I thought that target/site/apidocs (which is what our Javadoc script is failing when trying to access) was more a part of the "deployment" process, not something that I'd necessarily expect to see generated by javadoc:aggregate, which is what our Javadoc step runs.

But I'm also not having success when I tweak the Javadoc script to use mvn install, which I would have hoped would be pretty close to mvn deploy....

I can at least reproduce the green->red transition from https://github.com/google/truth/commit/02d56ddd663490a3b0040b5464270b3077dd41a2 to https://github.com/google/truth/commit/fceb336b3cc715c3cbfca6579cc3d2660360e279 (with the Javadoc script hacked up to use mvn clean source:jar javadoc:jar install javadoc:aggregate -DskipTests).

cpovirk commented 2 months ago

It looks like maven-javadoc-plugin changed the location that it outputs to in a commit titled "Align plugin implementation with AbstractMavenReport (maven-reporting-impl)".

cpovirk commented 2 months ago

This wasn't supposed to be closed yet, but GitHub latched onto the final two words of...

This CL started as an excuse to see whether cl/681051228 has fixed https://github.com/google/truth/issues/1343

Anyway, I did confirm that the Sonatype issue is fixed, so we're just waiting on the Javadoc fix, which is out for review.

cpovirk commented 1 month ago

Also affected: jimfs. That should be fixed by https://github.com/google/jimfs/commit/42851632afb6db1f9185dcdf8f242542e00267c6 and my update of the secrets, assuming that I have push permissions for jimfs.... [edit: confirmed fixed for google/jimfs@3dc7cca]

The other projects that I checked all looked good.