Closed yannchauvel closed 3 years ago
@yannchauvel I tried to reproduce the issue you are seeing and was not able to make it fail. That said, I was using the latest code (basically v0.0.16) in a docker container running NXRM 3.29.2-02.
I noticed the stack trace in the log you posted did not have the line numbers in the same place as I saw the code in NXRM 3.29.2-02. Is it possible that trace was running an older/different version of Nexus Repository Manager? (You mentioned testing with a lot of versions, so just wanted to double check).
I also noticed that log shows a GET to: uri=http://nexus-integ01.<myorganisation>/repository/composer-groupe/packages.json
. Just wondering if there could be a NXRM version mismatch lurking?
I was able to test the proxy repo by building nexus-repository-composer
and running the docker container via:
docker build -t nexus-repository-composer .
docker run -d -p 8081:8081 --name nexus-repository-composer nexus-repository-composer
...stuff to get admin password, etc...
docker exec -it nexus-repository-composer /bin/bash
cat /nexus-data/admin.password
I setup a new proxy repo componser-proxy
pointing to https://packagist.org/
I setup a test composer project to hit this proxy repo.
composer config repo.nxrmproxy '{"type": "composer", "url": "http://192.168.1.125:8081/repository/composer-proxy/"}'
composer config repositories.packagist false
composer config secure-http false
And I was able to update and build the test project via that Nexus proxy.
composer update
vendor/bin/phpunit tests
Perhaps you could try recreating the steps I took above? That would validate the format working in your environment, and allow you to test some builds against a clean NXRM repo.
Next you could start introducing your Nexus data volumes etc. If you are using a proxy alone, perhaps starting from a new NXRM is easier? If you are also using a hosted composer repo, is republishing in a new NXRM an option?
I apologize upfront, as I'm new to PHP and by no means a format expert, so please don't laugh too hard at my silly questions.
Hi Dan, thank you for short reply.
I replayed the steps you played on your side and this time I was successful. I also replayed my pipeline that failed in the first place, and this time no failure occured. I'm quite puzzled since I should get similar result while replaying my CI/CD pipeline. And last week I have been able to reproduce before logging this issue.
Which leads me to think that the only change comes from the docker data volume that I am restoring from daily production environment backup. So far the only explanation is that some composer asset was corrupted in some way, leading to the issue. I should be able to restore data volume from last week from archives, but it will cost me time, which I can't afford right now.
Anyway, now I successfully achieved building my docker stack with nexus3:3.29.2 and nexus-repository-composer 0.0.16 (latest). I guess this issue can be closed. Thank you for the time spent on your reply and tests.
Glad to hear you got it sorted! Thanks for closing the loop.
Thanks for creating an issue! Please fill out this form so we can be sure to have all the information we need, and to minimize back and forth.
1/ build new docker image with composer plugin :
2/ deploy stack with built docker image and pre-existing nexus data volume :
Nexus is starting without error and nexus-repository-composer bundle seems to be loaded correctly : The nexus-repository-composer plugin appears normaly in the System/Bundle administration UI menu.
3/ From the User UI menu, browse my composer proxy repository. A click on any composer asset should display asset's metadata in the right panel (summary, attributes ...) Instead I get an error popup that says :
UncaughtTypeeError: b.get is not afunction (https://nexus-integ01.myorganisation.com/static/rapture/nexus-repository-composer-prod.js?_v=3.29.2-02&_e=PRO.1
4/ Pulling an asset through composer-packagist proxy repository gives me this error :
What feature or behavior is this required for? I need Composer proxy repositories. On 3.26.1, the plugin composer plugin (version 0.0.7) was working correctly : creating composer proxy repositories, pulling assets from them through composer group repository
How could we solve this issue? (Not knowing is okay!)
Anything else? I captured the exception in administration UI menu 'Support/Logging/Log Viewer' while getting this error, see attached file. nexus-composer-error-logs.log
Last thing, the deployment of my Nexus server is fully automated in a CI/CD pipeline.
I am able to successfully deploy Nexus v. 3.26.1 and nexus-repository-composer v. 0.0.7 in an automated CI/CD pipeline (it has been in production for several months and working smoothly). Switching to Nexus v 3.29.2 and nexus-repository-composer triggers this issue. I have tested several nexus-repository-composer versions : 0.0.7, 0.0.8, 0.0.12, 0.0.14, 0.0.16, to no avail.