Action silently reports success when server rejects the upload

[awdeorio]

Describe the bug

The action silently reports a successful upload even when the server rejects it. There is no -f/--fail on the curl call and the action does not check curl's exit code or the HTTP status, so any 4xx/5xx response from https://preview.sesh.rs/upload-site-preview (e.g. a 403 because the repo is missing from UPLOAD_APP_SECRETS, or a 400 from a bad payload) is logged as Uploaded to Primer Spec Preview. The action then posts a PR comment linking to a preview URL that returns 404 forever.

This made a real misconfiguration on a new repo very hard to diagnose: a green check on the workflow, a "successful" upload in the log, and a PR comment with a preview link — but the link always 404'd because the upload had actually been rejected.

To Reproduce

Steps to reproduce the behavior:

1. Configure a repo to use seshrs/upload-to-primer-spec-preview@v1 but make sure it is not registered in the server's UPLOAD_APP_SECRETS map (or use a wrong secret value).
2. Open a PR that modifies docs/** so the workflow runs.
3. The workflow run is green. The log shows:

   curl -F repo=<owner>/<repo> -F app_secret=*** -F pr_number=<n> -F site=@_site.tar.gz https://preview.sesh.rs/upload-site-preview
   ...
   100 4371k    0     0  100 4371k      0  5923k --:--:-- --:--:-- --:--:-- 5931k
   Uploaded to Primer Spec Preview
   

   Note the Received column is 0 — the server returned status 403 with an empty body, which is what return 403 from Sinatra produces. The action logs "Uploaded to Primer Spec Preview" anyway and continues.
4. The action posts a PR comment with https://preview.sesh.rs/previews/<owner>/<repo>/<n>/, which 404s.

Expected behavior

When the server returns a non-2xx response, the action should fail. Specifically:

• The Action step should be marked failed with the HTTP status and response body shown in the log.
• No PR comment should be posted linking to a preview that doesn't exist.

Screenshots

n/a — log output is captured under "To Reproduce".

Desktop (please complete the following information):

n/a — this is a GitHub Actions runner issue.

• Action: seshrs/upload-to-primer-spec-preview@v1
• Runner: ubuntu-latest

Additional context

The relevant block is in src/main.ts (around the curl invocation):

const result = execa.commandSync(curlCommand);
core.info(result.stdout);
core.info(result.stderr);
core.info("Uploaded to Primer Spec Preview");

• curl has no -f/--fail, so it exits 0 on 4xx/5xx.
• result.exitCode and the HTTP status are never checked.
• The success log line is unconditional, and the PR-comment step that follows runs regardless.

Suggested fixes, in increasing order of robustness:

1. Minimum: Add --fail-with-body to the curl invocation. curl will then exit non-zero on HTTP ≥400 while still printing the response body, execa.commandSync will throw, and core.setFailed will surface the failure.
2. Better: Drop curl, use @actions/http-client or node-fetch, check response.statusCode, and core.setFailed with the response body when not 2xx.
3. Nice to have: Don't post the PR comment when the upload didn't return 2xx, so we don't advertise broken previews.

Happy to send a PR if that would help.

Example failing run (a real instance of this in the wild):
https://github.com/eecs485staff/p3-chat485-clientside/actions/runs/25392876603