Fix Windows release upload: idempotent get-or-create + fail-loud #6
Reference in New Issue
Block a user
Delete Branch "feature/ux-improvements"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Problem
The Windows
Upload to Gitea releasestep (cmd-batch) unconditionallyPOSTed to/releases. On a re-run thev{VERSION}-wintag already exists, so Gitea returns 409, thefindstrid parse yields an empty RELEASE_ID, and uploads go to a malformed.../releases//assetsURL.cmdandcurl -sswallowed every error, so the step reported success while attaching no assets (the blankRelease ID:in the logs).Fix
Rewrite the step in PowerShell, mirroring the logic the macOS job already uses:
$ErrorActionPreference = Stop,curl.exe -fsSwith retries/backoff/timeout, and a$LASTEXITCODEcheckNote
This is separate from the recent red Windows jobs, which were caused by the self-hosted
home-windowsrunner going offline (Windows reboot for updates never fully booted, so the runner service didn't start) and Gitea reaping the stale task. That has been resolved out-of-band (runner upgraded + brought back online).🤖 Generated with Claude Code
The cmd-batch upload step POSTed to /releases unconditionally. On a re-run the v{VERSION}-win tag already exists, so Gitea returns 409, the findstr id parse yields an empty RELEASE_ID, and uploads go to a malformed .../releases//assets URL -- all silently swallowed by cmd and `curl -s`, so the step reported success while attaching no assets. Rewrite in PowerShell mirroring the macOS job: look the release up by tag first and create only on 404, throw if the id can't be resolved, delete same-named assets left over from partial runs before re-upload, and fail loudly (ErrorActionPreference=Stop, curl.exe -fsS with retries, $LASTEXITCODE check). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>