release: cross-build Windows .exe + upload to forgejo release assets #102

New issue

Closed

opened 2026-05-27 00:02:32 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-05-27 00:02:32 +00:00

Owner

Problem

Forgejo is now canonical for coily releases (closed by #80), but the Forgejo release pipeline only tags + creates the release. It does not cross-build the Windows .exe and does not upload binary assets. Releases v2.38.0 through v2.40.2 all ship with assets: 0 per the Forgejo API. The old GitHub release flow used to upload coily-windows-amd64.exe / -arm64.exe; that job did not get carried across in #80 ("Not migrated in this change... Blocked on migrating scoop-bucket to forgejo (separate sweep)").

This blocks the scoop-bucket Forgejo migration (companion issue in coilysiren/scoop-bucket) and breaks make install-windows parity with brew install coily.

Change

.forgejo/workflows/release.yml: add a cross-build step that runs go build -tags prod -o coily-windows-amd64.exe ./cmd/coily under GOOS=windows GOARCH=amd64 (and arm64), then uploads both as Forgejo release assets via coily ops forgejo release upload-asset (the verb from #75) or the equivalent shared composite action under coilysiren/agentic-os/actions/.
Same step emits coily-windows-amd64.exe.sha256 / -arm64.exe.sha256 so the scoop manifest's hash.url autoupdate keeps working.
Backfill v2.40.2 with assets after the pipeline lands, so the scoop-bucket cutover has a working "latest" to point at.

Why now

Supersedes the GitHub-Actions plan in #50, which is stale post-#80. Companion issue in coilysiren/scoop-bucket flips the manifest the moment assets exist.

Out of scope

Signed Windows binaries.
MSI / winget.

Closes the Windows-half of #50 (the scoop-bucket companion closes the rest).

**Problem** Forgejo is now canonical for coily releases (closed by #80), but the Forgejo release pipeline only tags + creates the release. It does not cross-build the Windows `.exe` and does not upload binary assets. Releases v2.38.0 through v2.40.2 all ship with `assets: 0` per the Forgejo API. The old GitHub release flow used to upload `coily-windows-amd64.exe` / `-arm64.exe`; that job did not get carried across in #80 ("Not migrated in this change... Blocked on migrating scoop-bucket to forgejo (separate sweep)"). This blocks the scoop-bucket Forgejo migration (companion issue in `coilysiren/scoop-bucket`) and breaks `make install-windows` parity with `brew install coily`. **Change** - `.forgejo/workflows/release.yml`: add a cross-build step that runs `go build -tags prod -o coily-windows-amd64.exe ./cmd/coily` under `GOOS=windows GOARCH=amd64` (and `arm64`), then uploads both as Forgejo release assets via `coily ops forgejo release upload-asset` (the verb from #75) or the equivalent shared composite action under `coilysiren/agentic-os/actions/`. - Same step emits `coily-windows-amd64.exe.sha256` / `-arm64.exe.sha256` so the scoop manifest's `hash.url` autoupdate keeps working. - Backfill v2.40.2 with assets after the pipeline lands, so the scoop-bucket cutover has a working "latest" to point at. **Why now** Supersedes the GitHub-Actions plan in #50, which is stale post-#80. Companion issue in `coilysiren/scoop-bucket` flips the manifest the moment assets exist. **Out of scope** - Signed Windows binaries. - MSI / winget. Closes the Windows-half of #50 (the scoop-bucket companion closes the rest).

coilysiren referenced this issue from a commit

2026-05-27 00:08:32 +00:00

feat(actions): add upload-release-asset composite

coilysiren referenced this issue from a commit

2026-05-27 00:11:25 +00:00

feat(release): cross-build windows .exe + upload as forgejo assets

coilysiren closed this issue

2026-05-27 00:11:25 +00:00

coilysiren referenced this issue from a commit

2026-05-27 00:29:40 +00:00

feat(coily): point manifest at forgejo releases, bump v2.29.1 → v2.41.0