sonatype-nexus-community / nexus-repository-composer

Composer support for the Nexus Repository Manager (work in progress!)
Eclipse Public License 1.0
214 stars 81 forks source link

composer plugin not working after upgrade from nexus3:3.26.1 to 3.29.2 #90

Closed yannchauvel closed 3 years ago

yannchauvel commented 3 years ago

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 :

echo 'FROM sonatype/nexus3:3.29.2
USER root
COPY ./nexus-repository-composer-0.0.16.jar /opt/sonatype/nexus/deploy/
USER nexus
' > Dockerfile
docker build -t pci/nexus3:3.29.2 -f Dockerfile .

2/ deploy stack with built docker image and pre-existing nexus data volume :

services:
  nexus:
    image: pci/nexus3:3.29.2
    volumes:
      - nexus-data:/nexus-data
    ports:
      - "8081:8081"
      - "5000:5000"
      - "8700-8799:8700-8799"
    deploy:
      mode: replicated
      replicas: 1
volumes:
  nexus-data: {}
' > docker-compose-swarm.yml
docker stack deploy -c docker-compose-swarm.yml nexus

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

Sans titre

4/ Pulling an asset through composer-packagist proxy repository gives me this error :

[Composer\Downloader\TransportException (500)]
  The "http://nexus-integ01.myorganisation.com/repository/composer-packagist/packages.json" file could not be downloaded (HTTP/1.1 500 Server Error)

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.

bhamail commented 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.

yannchauvel commented 3 years ago

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.

bhamail commented 3 years ago

Glad to hear you got it sorted! Thanks for closing the loop.