drover.exe is now a GUI subsystem binary:
- Double-click no longer flashes a console window — a clean
smoke-test message box opens immediately.
- When run from cmd / PowerShell, AttachConsole reattaches stdout
and stderr to the parent terminal so '--version', 'check', etc.
still print as expected.
- MB_TOPMOST flag added to MessageBox so the window can't be
obscured by other windows on launch (this was the actual cause
of "I clicked but nothing happened" reports).
Verified locally: built with GOOS=windows GOARCH=amd64 -H=windowsgui;
running drover-gui.exe --version prints to PowerShell, drover-gui.exe
gui shows the message box on top of the active window.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Pay ~10s per job to install Node so actions/cache@v4 works, then
restore Go module cache (~/go/pkg/mod + ~/.cache/go-build) and apt
package cache (/var/cache/apt/archives + /var/lib/apt/lists).
Expected impact:
- Cold run (first push after this commit): same as before, plus ~10s
Node install. Cache populates.
- Warm runs: Go modules instant instead of ~15s download, apt install
~10s instead of ~60s. Net save ~60s per run.
Cache keys:
- Go: go-${runner.os}-${hashFiles('**/go.sum')} — invalidates on any
go.sum change.
- Apt: apt-trixie-wine-innoextract-v1 — bump version (-v2, -v3) when
the package list in 'Install Wine + Inno Setup' step changes.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Root cause of the earlier "Failed to authenticate" / "could not read
Username" failures: shell scripts in Gitea Actions don't automatically
inherit secrets — \${GITHUB_TOKEN} expanded to an empty string, so the
URL became "https://forgejo-runner:@..." (empty password) and Gitea's
auth layer rejected it.
Fix: explicit env: block on the Checkout step pulls the token in,
then the URL uses it via x-access-token (canonical token-as-password
username, accepted by Gitea, GitHub, Forgejo alike).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both 'forgejo-runner:$TOKEN' and 'x-access-token:$TOKEN' formulas
are rejected by Gitea's act_runner with HTTP 401:
remote: Failed to authenticate user
fatal: Authentication failed
For public repos the simplest fix is: don't send credentials at all.
Plain https://host/owner/repo.git clones unauthenticated and Gitea
serves it (root/drover-go is public).
If/when we move to private repos this'll need a different approach
(GITEA_TOKEN env, oauth2 username, or .netrc) — but that's a future
problem.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The hardcoded "forgejo-runner" username worked on Forgejo because its
runner accepted any user when the password is a valid GITHUB_TOKEN.
Gitea's act_runner v0.6+ rejects unknown usernames with:
remote: Failed to authenticate user
fatal: Authentication failed for 'https://git.okcu.io/.../...'
x-access-token is the canonical "the password IS the token" username
on GitHub Actions and works equally on Gitea, Forgejo and gitea.com.
Run that surfaced the issue: gitea run #1, task 1, sha 0f63f15,
"Cloning into '/tmp/src'... remote: Failed to authenticate user".
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After Forgejo→Gitea migration, the new server only scans
.gitea/workflows/ (and .github/workflows/ as fallback) for action
definitions. .forgejo/workflows/ is Forgejo-specific and ignored.
Both files (build.yml, release.yml) move as-is — the YAML schema
itself is identical between Forgejo Actions and Gitea Actions
(both forks of GitHub Actions schema).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
root