Have a non-zero exit code when curl fails about composer HOT 9 CLOSED

100 it is ;)

The CI failure is just php 8.4.

from composer.

I cannot reproduce this..

$ composer update
Loading composer repositories with package information
https://repo.packagist.org could not be fully loaded (curl error 7 while downloading https://repo.packagist.org/packages.json: ), package information was loaded from the local cache and may be out of date

In CurlDownloader.php line 372:

  curl error 7 while downloading https://repo.packagist.org/p2/arcanedev/log-viewer.json:


update [--with WITH] [--prefer-source] [--prefer-dist] [--prefer-install PREFER-INSTALL] [--dry-run] [--dev] [--no-dev] [--lock] [--no-install] [--no-audit] [--audit-format AUDIT-FORMAT] [--no-autoloader] [--no-suggest] [--no-progress] [-w|--with-dependencies] [-W|--with-all-dependencies] [-v|vv|vvv|--verbose] [-o|--optimize-autoloader] [-a|--classmap-authoritative] [--apcu-autoloader] [--apcu-autoloader-prefix APCU-AUTOLOADER-PREFIX] [--ignore-platform-req IGNORE-PLATFORM-REQ] [--ignore-platform-reqs] [--prefer-stable] [--prefer-lowest] [-m|--minimal-changes] [-i|--interactive] [--root-reqs] [--] [<packages>...]

$ echo $?
1

Maybe your CI or whatever you use to call composer there is swallowing the exit code?

from composer.

@Seldaek my bad, I found the culprit swallowing the exit code. Thank you!

from composer.

@Seldaek on a related note, is there a way to specify retries after a backoff period? I get connection issues often enough to warrant retries.

The exit code 1 isn't enough for me to know that it is a packagist connection issue to script a retry, and also because every CI failure leads to notifying the whole team, I don't want them to become accustomed to these false alarms.

I found this #10161, seems retry is built-in and automatic?

https://github.com/composer/composer/blob/bcab1c4b8ecf7b239dd9e08fc07c5458cf80cb0a/src/Composer/Util/Http/CurlDownloader.php can't quite see if there is a backoff period.

from composer.

There is backoff here

I fixed the return code now so it should use 255 for http/curl errors.

from composer.

@Seldaek as usual, I really appreciate your openness to suggestions and feedback.

I did some quick googling for standardized exit codes and it would appear 255 and some others are reserved https://tldp.org/LDP/abs/html/exitcodes.html#AEN23549

1. https://www.cyberciti.biz/faq/linux-bash-exit-status-set-exit-statusin-bash/ not sure what this is based on, but it has 100-104 for network problems
2. https://stackoverflow.com/a/1535733/3872647 there is 68 and 76

Would you like me to look for a suitable number?

from composer.

The backoff seems to be too small to deal with rate limiting, at least that is what I assume packagist was doing. I was thinking on the order of up to 30-60 seconds.

But no big deal, if the appropriate exit code is returned, I will handle these customized timeouts myself. Thank you.

from composer.

Packagist should not do rate limiting no, so I'm not sure why these failures occur.

Unfortunately I cannot really set a code <255 without breaking a bunch of internal code relying on the exception codes being http codes.

Exception::getCode is final so I can't do hackery there to return another code when symfony/console's Application class requests it. So I had to resort to another level of hackery.. but 762f2a3 should do the job.

from composer.

Ok, 255 it is. Thank you!

Wait, it appears 762f2a3 will return 100, but what does that red X mean? I thought the CI failed?

from composer.