Nexus values update
Package Merge Request
Package Changes
Setting the nexus metrics user creation job to true
by default. The Job is conditional on monitoring, so it can be templated similarly.
There is documentation to support this change in the package MR below. Ultimately this should provide an out-of-the-box method for successful serviceMonitor
authentication - with additional steps the enhance security of Nexus by allowing the Nexus admin credentials to be removed from the cluster.
Package MR
https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/nexus/-/merge_requests/80/commits
For Issue
Relates to https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/nexus/-/issues/52
Merge request reports
Activity
changed milestone to %1.52.0
added nexus statusdoing labels
assigned to @brandt.w.keller
added statusreview label and removed statusdoing label
requested review from @ryan.j.garcia, @BrandenCobb, @rob.ferguson, and @micah.nagel
added 81 commits
-
702c6274...ade18bbb - 80 commits from branch
master
- c7a85d03 - Merge branch 'master' of https://repo1.dso.mil/platform-one/big-bang/bigbang...
-
702c6274...ade18bbb - 80 commits from branch
mentioned in commit 08ce601d
@brandt.w.keller sorry missed the comment here earlier. My preference in most cases like this where a docs update depends on a BB change would be to actually update the version of the package chart so that it can be pulled into a BB MR.
Not sure if that makes complete sense, but would allow for...
- BB MR including both the change + pointing to a new tag with updated docs
- docs website, etc will have the right tag reference for the new version
It does feel a little weird to tag something with a new version for a docs only change, but I do think it is helpful in some scenarios like this. In this case it didn't end up mattering since there was another Nexus MR right after, so the BB release will have the updated docs regardless.
mentioned in issue #1406 (closed)