-
Notifications
You must be signed in to change notification settings - Fork 260
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
Comments
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:
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.... |
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. |
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.) |
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.) |
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 But I'm also not having success when I tweak the Javadoc script to use I can at least reproduce the green->red transition from 02d56dd to fceb336 (with the Javadoc script hacked up to use |
It looks like |
- 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
This wasn't supposed to be closed yet, but GitHub latched onto the final two words of...
Anyway, I did confirm that the Sonatype issue is fixed, so we're just waiting on the Javadoc fix, which is out for review. |
….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
This is the jimfs equivalent to google/truth#1346, since jimfs is also suffering from (both parts of) google/truth#1343.
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. |
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.The text was updated successfully, but these errors were encountered: