Skip to content
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

Sonatype and Javadoc snapshots both failing since recently #1343

Closed
cpovirk opened this issue Oct 1, 2024 · 8 comments · Fixed by #1345 or #1346
Closed

Sonatype and Javadoc snapshots both failing since recently #1343

cpovirk opened this issue Oct 1, 2024 · 8 comments · Fixed by #1345 or #1346
Assignees
Labels
P2 has an ETA

Comments

@cpovirk
Copy link
Member

cpovirk commented Oct 1, 2024

I assume that Sonatype is the same issue as google/auto#1832.

Javadoc appears to have broken with the maven-javadoc-plugin update of #1333.

@cpovirk cpovirk added the P2 has an ETA label Oct 1, 2024
@cpovirk cpovirk self-assigned this Oct 1, 2024
@cpovirk
Copy link
Member Author

cpovirk commented Oct 1, 2024

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
Copy link
Member Author

cpovirk commented Oct 1, 2024

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
Copy link
Member Author

cpovirk commented Oct 1, 2024

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
Copy link
Member Author

cpovirk commented Oct 1, 2024

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
Copy link
Member Author

cpovirk commented Oct 1, 2024

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 02d56dd to fceb336 (with the Javadoc script hacked up to use mvn clean source:jar javadoc:jar install javadoc:aggregate -DskipTests).

@cpovirk
Copy link
Member Author

cpovirk commented Oct 1, 2024

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)".

copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
- Continue changing docs to say "Checks that..." instead of "Fails unless...." I'd mentioned this in cl/680668770 but not done it. See also the somewhat similar cl/178917870.
- Continue changing docs to say "value under test" instead of "subject" when referring to, well, the value under test. I'd done a little of this in cl/680668770.
- Fill in some boilerplate Javadoc for the other `assertThat` overloads. I'd commented upon this in b/368371914. This continues a path that I've been very gradually pursuing in cl/166715211, cl/246871754, and cl/633264611.

This CL started as an excuse to see whether cl/681051228 has fixed #1343, but then I realized that I don't actually need a separate CL to test that. (Contrast to the _Sonatype_ fix, which _does_ require another CL.) But hey, it's not a bad thing to do, anyway.

RELNOTES=n/a
PiperOrigin-RevId: 681066698
@cpovirk
Copy link
Member Author

cpovirk commented Oct 1, 2024

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 #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 cpovirk reopened this Oct 1, 2024
copybara-service bot pushed a commit that referenced this issue Oct 1, 2024
….0`.

This should fix Javadoc snapshots.

Also, remove some Javadoc munging that hasn't had any effect for a while now.

Fixes #1343

RELNOTES=n/a
PiperOrigin-RevId: 681051228
cpovirk added a commit to google/jimfs that referenced this issue Oct 7, 2024
This is the jimfs equivalent to
google/truth#1346, since jimfs is also suffering
from (both parts of) google/truth#1343.
@cpovirk
Copy link
Member Author

cpovirk commented Oct 7, 2024

Also affected: jimfs. That should be fixed by google/jimfs@4285163 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P2 has an ETA
Projects
None yet
1 participant