Surface the Forge API response in the tag_deploy Forge step

[silug]

curl --fail discards the response body, so a failed Forge publish reports only a bare HTTP status — the simp-gpasswd 2.0.0 release died with an unexplained 403 (valid token, new-module creation refused; the Forge's JSON error would have said why outright).

The deploy step now captures the response body and status via --write-out/--output, prints both, and fails on any non-2xx result. Same upload semantics otherwise (also quotes the find properly, replacing the odd ''*.tar.gz'' quoting).

Note for #42: that branch rewrites tag_deploy.yml wholesale — I've applied the same step change there so the two merge cleanly in either order.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XCnDsYaJDLiP8z8tafz9Tp

[silug]

Added a second robustness improvement prompted by the gpasswd post-mortem: the built module archive is now uploaded as a workflow artifact before the Forge POST, so every tag run — pass or fail — leaves the exact tarball downloadable from the run page (previously a failed upload left nothing: no artifact, and the GitHub release carries no assets). Mirrored to #42 as before.

[silug]

Third improvement: the module archive is now also attached to the GitHub release (gh release upload --clobber, default GITHUB_TOKEN — same token the release-creation job already uses). Assets are permanent and public, unlike workflow artifacts (authenticated, 90-day expiry), and the upload happens before the Forge POST so a failed publish still leaves the exact archive on the release page. Note: prerelease tags skip this whole job (existing if:), so prereleases get neither Forge nor assets — unchanged behavior. Mirrored to #42.

[hcaballero2]

Skeptical review — I went looking for the usual failure modes in "attach assets + surface API errors" changes and verified the PR's claims against the actual branch contents rather than the description. What checks out:

• Ordering is sound. deploy-to-puppet-forge has needs: [create-github-release], so the release exists before gh release upload runs — no race. And attaching before the Forge POST is the right order, not just for evidence-preservation: the inverse order plus a transient attach failure would force a job re-run whose Forge POST would then 409 on the already-published version.
• The prerelease claim is accurate: the skip is the job-level if: needs.create-github-release.outputs.prerelease != 'yes', so the new artifact/attach steps can't run for prereleases (where no non-draft release semantics would apply).
• The token claim is accurate: create-github-release already does gh release create with the default GITHUB_TOKEN, so gh release upload needs nothing the workflow doesn't already rely on.
• actions/upload-artifact@v7 is the current major (v7.0.1), and if-no-files-found: error means a missing tarball now fails fast at the artifact step instead of producing a cryptic curl --form file=@ error two steps later.
• The "mirrored to #42" claim is true — openvox9-ruby4-template-refresh carries the identical three-step change (verified lines 188/196/202-215 of its tag_deploy.yml).
• Error handling holds up at the transport level too: GitHub run: steps default to bash -e, so a non-HTTP curl failure (DNS, TLS) fails the step at the http_code= assignment with --show-error output; the case only needs to cover HTTP-level failures, which is exactly what the old --fail was eating. Failing on 3xx (which --fail did not) is a behavior change, but a correct one for a POST that should never redirect.

Two small suggestions inline; neither blocks.