Debian-based Docker images install /etc/apt/apt.conf.d/docker-clean
which runs 'apt-get clean' after every apt-get install — wipes out
/var/cache/apt/archives so there's nothing for actions/cache to save.
Fix: remove the docker-clean drop-in and add keep-cache config first
thing in each job, before any apt activity. Also bump apt cache key
to v2 since the previous v1 was always empty.
Wait time on the Wine + Inno Setup step should drop from ~1m20s to
~10s on warm runs (debs already in /var/cache/apt/archives, dpkg
just installs them locally).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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>
Wine bailed with 'init_peb ... experimental wow64 mode / failed to
load syswow64/ntdll.dll' on 'wine ISCC.exe'. wine32:i386 ships the
needed 32-bit Wine internals; we already had dpkg --add-architecture
i386 from earlier (carried over).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
xvfb-run wraps wine in a fake X display, but it shells out to xauth
to set up the cookie. xauth isn't part of the xvfb package on
Debian trixie. Add it explicitly.
Failure: 'xvfb-run: error: xauth command not found' (run #7, task 8).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
innoextract 1.11/1.10/1.9 in Debian trixie chokes on 6.4.3 too — actual line where innoextract added 6.4 support requires upstream HEAD. 6.2.2 is the last version reliably parsed by innoextract 1.9+ which is what trixie ships.
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