We use Nexus to host an NPM registry containing only scoped packages. Packages are published either with the "latest" tag or a tag of the format "feat-name-of-new-feature". To reduce disk usage, we have a Cleanup policy that removes all packages containing "-feat-" that are X days old. The cleanup policy runs periodically (once every hour). Whenever the Cleanup policy actually identifies packages that should be removed and deletes them, the "latest" tag does not point anymore to a package that was published with the "latest" tag, but to a package with a "feat-xxx" tag that happens to have the highest version number.
For example.
Situation before cleanup policy:
latest points to @packagescope/examplepackage:2.1.4
feat-a points to @packagescope/examplepackage:2.2.0-feat-a.1
feat-b points to @packagescope/examplepackage:3.0.0-feat-b.4
Situation after running the cleanup:
latest points to @packagescope/examplepackage:3.0.0-feat-b.4
feat-a points to @packagescope/examplepackage:2.2.0-feat-a.1
feat-b points to @packagescope/examplepackage:3.0.0-feat-b.4
Obviously, this is wrong, and users that want to use the stable "latest" versions now suddenly get a package from a feature-branch that is often not even functional. The bug is very blocking.
Do you have a workaround you are using at present?
Yes, we disabled the cleanup policy, which is something we can do as long as we have disk space.
What feature or behavior is this required for?
How could we solve this issue? (Not knowing is okay!)
I suspect that Nexus implemented its own algorithm to determine the "new" latest after packages were removed, but does not respect the tags a package was initially published with.
Tell us about your Nexus Repository deployment: what version, operating system, and database are you using?
Sonatype Nexus OSS 3.61, running on ubuntu 22.04, with the default database type (not the new postgres).
Anything else?
We are in the process of testing this on 3.71, but due to holiday season this takes longer than normal. Given that the changelog does not report bugfixes that sound similar, I decided to already post this issue report.
This issue is present on our setup as well and also blocks our node module cleanup. This is one of the reasons we evaluate moving to another package registry like Artifactory.
We use Nexus to host an NPM registry containing only scoped packages. Packages are published either with the "latest" tag or a tag of the format "feat-name-of-new-feature". To reduce disk usage, we have a Cleanup policy that removes all packages containing "-feat-" that are X days old. The cleanup policy runs periodically (once every hour). Whenever the Cleanup policy actually identifies packages that should be removed and deletes them, the "latest" tag does not point anymore to a package that was published with the "latest" tag, but to a package with a "feat-xxx" tag that happens to have the highest version number.
For example.
Situation before cleanup policy:
Situation after running the cleanup:
Obviously, this is wrong, and users that want to use the stable "latest" versions now suddenly get a package from a feature-branch that is often not even functional. The bug is very blocking.
Yes, we disabled the cleanup policy, which is something we can do as long as we have disk space.
I suspect that Nexus implemented its own algorithm to determine the "new" latest after packages were removed, but does not respect the tags a package was initially published with.
Sonatype Nexus OSS 3.61, running on ubuntu 22.04, with the default database type (not the new postgres).
We are in the process of testing this on 3.71, but due to holiday season this takes longer than normal. Given that the changelog does not report bugfixes that sound similar, I decided to already post this issue report.