The Windows Upload to Gitea release step (cmd-batch) unconditionally POSTed to /releases. 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. cmd and curl -s swallowed every error, so the step reported success while attaching no assets (the blank Release ID: in the logs).
Fix
Rewrite the step in PowerShell, mirroring the logic the macOS job already uses:
Get-or-create the release by tag (create only on 404) — no more 409 on re-runs
Throw if the release id can't be resolved
Delete same-named assets left over from a partial run before re-uploading (replace, not conflict)
Fail loudly: $ErrorActionPreference = Stop, curl.exe -fsS with retries/backoff/timeout, and a $LASTEXITCODE check
Note
This is separate from the recent red Windows jobs, which were caused by the self-hosted home-windows runner 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).
## Problem
The Windows `Upload to Gitea release` step (cmd-batch) unconditionally `POST`ed to `/releases`. 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. `cmd` and `curl -s` swallowed every error, so the step reported **success while attaching no assets** (the blank `Release ID:` in the logs).
## Fix
Rewrite the step in PowerShell, mirroring the logic the macOS job already uses:
- **Get-or-create** the release by tag (create only on 404) — no more 409 on re-runs
- **Throw** if the release id can't be resolved
- **Delete** same-named assets left over from a partial run before re-uploading (replace, not conflict)
- **Fail loudly**: `$ErrorActionPreference = Stop`, `curl.exe -fsS` with retries/backoff/timeout, and a `$LASTEXITCODE` check
## Note
This is separate from the recent red Windows jobs, which were caused by the self-hosted `home-windows` runner 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](https://claude.com/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>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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>