Codecov fail_ci_if_error limits with --no-upload flag

The fail_ci_if_error flag is intended to ensure CI jobs fail when coverage data is missing or cannot be parsed. Its check is tied to the upload phase of the Codecov CLI.

When the --no-upload flag is active, the uploader is bypassed entirely. In this configuration, parse errors are recorded in the CLI output but do not cause the process to exit with a non-zero code. The CLI completes normally, returning exit status 0, unless a fatal internal error occurs before the upload step would have run.

Answers to the specific questions

1. Does fail_ci_if_error cause a CI job to fail when --no-upload is active and a parse error occurs? No. The flag is only evaluated during the upload phase; with uploads suppressed, the check is never reached.
2. What is the expected exit status for a malformed coverage file when uploads are disabled? The CLI exits with status 0.
3. Is there a documented configuration to enforce CI failure on parse errors independently of the upload status? No. The only mechanisms that honor fail_ci_if_error require an actual upload attempt. Removing --no-upload or adding a separate validation step outside Codecov are the practical workarounds.

Verification in your environment

# Create a deliberately malformed coverage file
cat > bad.txt <<'EOF'
invalid coverage data
EOF

# Run Codecov with no-upload and observe exit code
codecov --no-upload bad.txt
echo Exit code: $?

Check the CLI output for a parse error message. If the exit code is 0, this confirms the described behavior. If a non-zero code appears, it may indicate a version-specific handling or a fatal error unrelated to parsing.

To enforce failure on parse errors without uploading, consider removing --no-upload or inserting an explicit coverage-validation step in your CI pipeline before the Codecov invocation.

Note: Behavior may vary between Codecov CLI releases. Which version are you running? The environment variable CODECOV_FAIL_CI_IF_ERROR may not be honored when uploads are disabled. If the CI system suppresses exit codes (e.g., GitHub Actions continue-on-error), the observed job status may not reflect the CLI exit code, which is an important consideration when designing pipeline error handling.