Add upload diagnostics and fail-on-error option

[joshhale]

Summary

Improves diagnostic output for the code coverage upload action and adds a fail-on-error option to control workflow failure behavior.

Problem

When the upload API returns a non-201 response (e.g. HTTP 200 for "commit is not latest on branch", or 4xx errors), the action currently swallows the response and exits successfully. Users have no way to tell whether their upload was actually accepted or silently rejected.

Changes

Diagnostic output

• Logs upload parameters (commit SHA, ref, PR number, language, label, file size) in a collapsed ::group:: block
• Captures and displays the HTTP status code from the API response
• On HTTP 201: emits a success notice with the report ID
• On HTTP 200: emits a ::warning:: with the API message (typically "commit is not the latest on branch")
• On 4xx/5xx: emits an ::error:: annotation with the status code and response body

fail-on-error input (default: false)

• New optional input that controls whether a failed upload causes the action (and therefore the workflow) to fail
• When false (default): errors are surfaced as annotations but the action exits 0, so existing workflows are not broken
• When true: the action exits 1 on non-success responses, useful for workflows that want to gate on coverage upload success

Backward compatibility

This is fully backward compatible. The default behavior is unchanged: the action still exits 0 on any response. The only visible difference is additional annotations in the workflow log.

[Copilot]

Pull request overview

This PR improves diagnostics for the code coverage upload step by surfacing upload parameters in a collapsed log group and reporting the HTTP status code (including differentiating 201 stored vs 200 accepted-but-not-stored) along with the response body to aid troubleshooting.

Changes:

• Log key upload parameters in a grouped section to keep workflow logs readable.
• Capture and report the HTTP status code and response body from the upload API call.
• Emit warnings/notices for non-201 outcomes to make “green but no report” scenarios easier to diagnose.

Show a summary per file

File	Description
action.yml	Adds grouped parameter logging and expands upload handling to parse/report HTTP status and response body.

Copilot's findings

Tip

Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

• Files reviewed: 1/1 changed files
• Comments generated: 2

[joshhale]

Testing the fail-on-error behaviour

First, against the current version of upload-code-coverage I verified that a 4xx upload failure causes the action run to fail:

https://github.com/joshhale/code-coverage-test/actions/runs/26042852804/job/76558955955?pr=1

Same behaviour when fail-on-error: true is set: https://github.com/joshhale/code-coverage-test/actions/runs/26043212473/job/76560259021

When fail-on-error: true is removed and we default to false the workflow passes, although it still logs the error (as intended):

https://github.com/joshhale/code-coverage-test/actions/runs/26043964721/job/76562969572?pr=1

Testing the logging

We see the upload parameters in the log. On 200 we get a warning that no action was taken:

No warning on 201:

[joshhale]

Retesting after tweaks

Success case:

200 case: