It seems certain packages with a certain format for the "platform" in the metadata doesn't parse the correct value. For example, for the package "libv8-node-188.8.131.52-x86_64-linux-musl.gem", the platform is picked up as "x86_64-linux" instead of "x86_64-linux-musl". Looking at the metadata file inside the package, we can see:
This causes issues with resolving the package through a remote repo, and with deploying the package to a local repo using "gem push".
-When deploying to a local repo with "gem push", the platform is incorrectly parsed (the -musl is stripped), so the package ends up being named "libv8-node-184.108.40.206-x86_64-linux.gem".
-When resolving through a remote repo, the package returns a 500. In the logs, you will see the attached stacktrace corresponding with the 500 error.
The package is resolvable through remote repositories without throwing a 500 error. Also, when deploying the package to a local repo, the correct "platform" value should be picked up.
-For remote repos, try to resolve the package via the below, and notice the 500 error:
-For local repos, download the package via:
curl https://rubygems.org/gems/libv8-node-220.127.116.11-x86_64-linux-musl.gem -L -O
-Then, try to upload the package to the repo using "gem push"
There doesn't seem to be a workaround resolving from a remote repo, but you can manually deploy the package via UI or curl to the gems folder of the local repo. So http://<url>/artifactory/gems-local/gems.
This will keep the name of the package as "libv8-node-18.104.22.168-x86_64-linux-musl.gem". Then, you can aggregate the local repo in a virtual, and resolve the package from the virtual.
Reproduced on RESTRICTED_URL (RESTRICTED_USERNAME,RESTRICTED_PASSWORD)