search

hyperledger / cacti

Hyperledger Cacti is a new approach to the blockchain interoperability problem
https://wiki.hyperledger.org/display/cactus
Apache License 2.0
327 stars 275 forks source link

docs(examples/supply-chain-app): print correct web host in the CLI logs #2390

Closed petermetz closed 4 weeks ago

petermetz commented 1 year ago

Describe the bug

The example supply chain app prints to the terminal that the cockpit is accessible via 0.0.0.0 while it is only accessible via localhost. The readme has localhost stated correctly but people tend to not read the documentation at all so it's much better if we fix the terminal logs as well (which should be fixed anyway because it's just wrong to print false information).

To Reproduce

Go through the supply chain app's guide/tutorial steps from the readme and then observe that the CLI prints 0.0.0.0 for the host instead of localhost

Expected behavior

The CLI prints true statements such as that the web GUI is accessible via localhost:$PORT.

Cloud provider or hardware configuration:

Local development machine (but also everywhere else)

Operating system name, version, build:

ubuntu-20.04

Hyperledger Cactus release version or commit (git rev-parse --short HEAD):

main and 1.2.0

Hyperledger Cactus Plugins/Connectors Used

N/A

monish-byte commented 1 year ago

hey @petermetz I am a beginner contributor. I really want to contribute to this project. Can you please guide me from where should I start?

anmolchhabra21 commented 1 year ago

@petermetz, I would like to work on this issue. Can you please assign me this?

deepto98 commented 1 year ago

Can I pick this up?

deepto98 commented 1 year ago

@petermetz I tried fixing this in https://github.com/hyperledger/cacti/pull/2428, and it currently prints 127.0.0.1 if I build the supply chain app locally, but if I build it using the Dockerfile, it still prints 0.0.0.0, I would need some help to understand this further.

petermetz commented 9 months ago

@deepto98 Sorry for the slow response! It does that because the Dockerfile installs the npm packages from the public rergistry not from your local codebase so what needs to happen is that the code you wrote that works locally (as in it prints 127.0.01) needs to be sent in as a PR then we merge that, then eventually it goes out with a release to npmjs.com and then the docker image can be built with the latest npm package which will contain the fix. A big chain of dependencies and a lengthy process but it helps with keeping track of fixes and features alike.

If you'd like to give it another shot feel free to re-open the PR, otherwise I'll just pick this up in a few days myself. I'm fine either way!