curl: Usage, Options & Common CI Errors
curl moves bytes between your runner and a URL, scriptably and without a browser.
curl is the default HTTP client in pipelines. The trick in CI is making it fail loudly and retry sensibly instead of silently writing an error page to a file.
What it does
curl transfers data from or to a server using URL syntax, supporting HTTP, HTTPS, FTP, and more. By default it prints the body to stdout and exits 0 even on HTTP 404/500 unless you pass -f.
Common usage
curl -fsSL https://example.com/script.sh | bash
curl -o out.tar.gz https://example.com/file.tar.gz
curl -H "Authorization: Bearer ${TOKEN}" https://api.example.com/v1/x
curl --retry 5 --retry-all-errors --retry-delay 2 https://example.com
curl -X POST -d '{"k":"v"}' -H 'Content-Type: application/json' https://api/xOptions
| Flag | What it does |
|---|---|
| -f / --fail | Exit 22 on HTTP >= 400 instead of writing the error body |
| -s / --silent | Hide progress meter and errors |
| -S / --show-error | Show errors even with -s |
| -L / --location | Follow redirects |
| -o <file> / -O | Write to file / use remote name |
| --retry N --retry-all-errors | Retry transient (and all) failures |
Common errors in CI
Exit codes are the key signal: 6 = could not resolve host (DNS/typo), 7 = failed to connect (port closed/down), 22 = HTTP error returned with -f (e.g. 404/401/500), 28 = operation timed out (add --max-time and --retry), 35 = SSL connect error (TLS handshake/proxy), 56 = failure receiving network data (connection reset). Always use -f so a 500 does not get piped into bash; use -sS so silent mode still shows the real error.