Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gz fuel download returns 0, even when the download failed #349

Open
dHofmeister opened this issue Apr 4, 2023 · 1 comment
Open

gz fuel download returns 0, even when the download failed #349

dHofmeister opened this issue Apr 4, 2023 · 1 comment
Assignees
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed

Comments

@dHofmeister
Copy link

Environment

Description

  • Expected behavior: return code non-zero
  • Actual behavior:error code zero
root@user-desktop:/gazebo# gz fuel download --url https://fuel.gazebosim.org/1.0/openrobotics/models/sydney_regatta
[Err] [FuelClient.cc:677] Failed to download model.
  Server: https://fuel.gazebosim.org
  Route: openrobotics/models/sydney_regatta/tip/sydney_regatta.zip
  REST response code: 504
Download failed.
root@user-desktop:/gazebo# echo $?
0

It would be nice to have a non-zero return code in the terminal, as it would make error handling and catching easier.

Greetings

@dHofmeister dHofmeister added the bug Something isn't working label Apr 4, 2023
@azeey azeey added help wanted Extra attention is needed good first issue Good for newcomers labels Apr 10, 2023
@M1chaelM
Copy link

This bug is particularly bad when working with Docker images. Since resources are not typically downloaded and cached until the first time they are needed, users running gz sim commands from a Docker image have to download everything from fuel every time unless they use gz fuel download to build the cache into the image. However, Docker relies on the error code to determine whether a step in its build process has succeeded. So when gz fuel download returns 0 even though it has failed, the result is that Docker does not detect the error, and bakes the failed download into the image.

If the user is not actively reading the console output they will think they've cached the resource when they haven't. Further, to fix the problem, the user will have to manually add a cache-bust argument to the appropriate spot in the Dockerfile, since Docker has no way of knowing which layer to start from.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers help wanted Extra attention is needed
Projects
Status: To do
Development

Successfully merging a pull request may close this issue.

4 participants