release: the openipc.org push succeeds on a 200 and nothing else

[openipc-ai]

Follow-up to #225.

curl -f fails only on status 400 and above. The first push after #225 got a 302 to openipc.org's home page, because the endpoint had no nginx location yet (OpenIPC/website follow-up). The step reported success anyway.

This change makes the step require a 200, print openipc.org's answer, and fail visibly on anything else. continue-on-error still keeps a failed push from failing the build.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

Require HTTP 200 for openipc.org release pushes

🐞 Bug fix ⚙️ Configuration changes 🕐 Less than 10 minutes

AI Description

• Reject redirects and other non-200 responses that previously appeared to be successful pushes.
• Print the server response and annotate failures without failing the overall build.

Diagram

graph TD
  A["Push step"] --> B["openipc.org API"] --> C["Print response"] --> D{"Status 200?"}
  D -->|Yes| E["Push succeeds"]
  D -->|No| F["Advisory failure"]

Loading

High-Level Assessment

The explicit status check fits the requirement: curl -f does not reject redirects, and the workflow already makes this push advisory. No additional HTTP tooling is warranted.

Files changed (1) +9 / -2

Bug fix (1) +9 / -2

release.ymlRequire HTTP 200 from the openipc.org push endpoint +9/-2

Require HTTP 200 from the openipc.org push endpoint

• Captures the PUT response body and status, prints the body, and emits a GitHub Actions error for any status other than 200. The step retains continue-on-error, so a rejected push does not fail the build.

.github/workflows/release.yml

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can add REVIEW.md to your repo root and Qodo follows it on every PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗