We are seeing customers Manually Blocking proxy repositories. These proxy repositories either remain in a group repo, or they may be accessed directly by builds. Still accessing the blocked repo is legitimate because it may have already cached content the customer wants.
In these cases for every uncached request, you may see WARN level log messages in your application nexus.log that contain text like this:
CacheInfo missing for ... assuming stale content.
Builds can fail because when asking for yet uncached, or expired content
- may be receiving 502 HTTP status code responses when accessing a NXRM proxy repository directly.
- receive a 404 HTTP status code when accessing a group repository containing the proxy repository
Person managing the build has no insight into why the build failed. Both status codes do not provide enough context. The developer researching the build failure is not an admin and cannot check repository settings. The build can seemingly access some content successfully proving the repo exists and permissions are correct, when accessing already cached content. During same build uncached content fails.
All of this creates friction
- nexus.log spammed with WARN messages noise simply because a repo is manually blocked by an admin - in some cases there could be hundreds of thousands of like these
- developer lacks understanding or a way to learn what is wrong with their build
A KB has been published:
- do not fill nexus.log with hundreds of thousands of log messages in this case
- provide a supported way for "person who manages build" to better learn the reason why their builds are failing to retrieve some content