Where the artifact at the end it changes from time to time (I mean, is not always express@^4.16.3)
Things I have checked so far.
I can login to Nexus through browser using the user and password that is defined on the upload.
I can login to Nexus repo through shell using the user and password defined on the upload.
I can upload the package using a local shell and using the same credentials.
During the execution, I did a curl -v repo-url and I get a correct response (so I assume I got network connectivity).
I have checked if was a proxy, and there was.
I deleted the proxy configuration
I changed to another proxy
I added a no proxy variable so I can except the FQDN of the Nexus URL Repo
I also checked if the package (in this case express@^4.16.3) exists on Nexus, and it does.
But in all cases I’m still getting the 403 error at the end.
To give a bit more of context.
This is using Jenkins.
And targetting a new nexus that I’m deploying.
If I use the old nexus I don’t have this issues. It only happens to the new version
And, I migrate all the data, so the same user that exists in the old nexus is in the new one and you can login with those credentials.
I have checked nexus.log and request.log but didn’t find any error.
Any idea in what else can I check or from where the issue could come from?
Try checking the request.log to see if the 403 is actually coming from Nexus Repo (it may be coming from something in between jenkins and nexus). If it is coming from Nexus Repo the user ID associated with the request will be printed in the third column. Make sure that user has write access to the repository.
I have checked request.log in nexus and I got no 403 error, (all of them are 200).
I also checked jenkins’ logs and there is no error within the time for the test.
The user has write access to the repo, as I said, If i use npm locally (from my computer) I can upload the artifact succesfully.
So the 403 is coming from somewhere else. One thing to check… if there is an http proxy server configured under manage jenkings → manage plugins you’ll likely need to add the nxrm host name to the bypass list.
I will check that…do you know if is something I can check from the server side? Rather than accessing to Jenkins?
There was one Proxy configured at server level (before this error, I got a message error saying Port Not allowed) but after I reconfigured the proxy from the Jenkins’ server, I didn’t get it.
Besides if I do curl from the Jenkins Job I get the connectivity, thats weird.
In case anyone comes to this error. Even configuring the proxy at server and container level didn’t worked. I’d found out that Jenkins has a proxy configuration at the application level. So I went into Jenkins, Administration section and configured the proxy properly. After that was done, it all started to work.