fix: update release tags with corrected flake hash
Problem
Users experience hash mismatch errors when trying to run WinBoat from release tags:
nix run github:TibixDev/winboat/v0.8.7
Error:
error: hash mismatch in fixed-output derivation '/nix/store/...-winboat-0.8.7-x64.tar.gz.drv':
specified: sha256-I7SoX0dcQoFucj/GRvORZvgdKTIc+7+F9COZS33nFuk=
got: sha256-4NV9nyFLYJt9tz3ikDTb1oSpJGAKr1I49D0VHqpty3I=
Root Cause
The update-flake-hash workflow has a timing issue:
- Release tag is created with an outdated hash from
flake.nix - Release artifacts are built and published
- Workflow calculates the correct hash and updates main branch
- Tag is never updated, so it still contains the wrong hash
When users reference a tag (e.g., v0.8.7), Nix uses the flake.nix from that tag, which has the incorrect hash.
Evidence
- Tag
v0.8.7(commita641ec8) has hash:1s8nwxylp693yj2vzyqw68livy36j7rldiizf9p82hjw8xgsid13(wrong - this is for v0.8.6) - Main branch has hash:
0wnbdnm1w59xyhw55bqac0jak16nvcs91qixnxyrnq2b46gpvmg0(correct for v0.8.7)
Solution
This PR modifies .github/workflows/update-flake-hash.yml to force-update the release tag after calculating and committing the correct hash. This ensures the tag points to a commit with the accurate hash matching the release artifacts.
Changes
- Added logic to force-update the release tag with the corrected
flake.nix - Tag now points to the commit with the matching hash for the release artifacts
Testing
Locally tested:
- ✅ Hash calculation matches the published v0.8.7 artifacts
- ✅ Sed replacement logic works correctly
- ✅ Tag force-update logic verified (creates and moves tags successfully)
- ✅ Built successfully from local clone with correct hash
Impact
- Fixes hash mismatch errors for all future releases
- Users can reliably use
nix run github:TibixDev/winboat/vX.Y.Z - Existing tags (v0.8.6, v0.8.7) will need manual correction or the workflow can be triggered manually to fix them
Fixes #164
Note: This PR also relates to #177, which reports that the update-flake-hash workflow isn't triggering on releases.
While this PR fixes the tag update logic (ensuring tags point to commits with correct hashes), there may be a separate issue with the workflow trigger itself. If the workflow isn't running at all, then this fix won't help until that's resolved.
The workflow trigger is currently:
on:
release:
types: [published]
If the workflow isn't triggering, we may also need to investigate:
- Whether releases are being published (vs created as drafts)
- Repository permissions for GitHub Actions
- Whether the workflow file exists on the default branch when releases are created
Both issues should be addressed for a complete fix.
Update: Now also fixes #177
I've updated this PR to comprehensively address both issues:
Root Cause Analysis
The workflow wasn't triggering automatically because:
- Releases created by
GITHUB_TOKENdon't triggerrelease: publishedevents (GitHub Actions limitation to prevent infinite loops) - Tags had incorrect hashes because the workflow only updated main, never the tags
Complete Solution
Changed trigger mechanism:
- ✅ Replaced
release: publishedwithworkflow_run - ✅ Triggers after "Build WinBoat" workflow completes
- ✅ Only runs on successful workflows triggered by tags
- ✅ Extracts version from
workflow_run.head_branch
Improved reliability:
- ✅ Replaces
sleepwith proper retry loop usingcurlto verify asset availability - ✅ Polls up to 30 times (5 minutes) with clear error messages
- ✅ Keeps
workflow_dispatchfor manual triggers
Tag update (original fix):
- ✅ Force-updates release tags to point to commits with correct hashes
Testing
All workflow logic has been validated:
- ✓ Version extraction from tag refs
- ✓ URL format correctness
- ✓ Retry loop logic
- ✓ Workflow trigger conditions
- ✓ Asset availability checking
Impact
This fix ensures:
- Workflow runs automatically after each tagged release
- No more manual workflow_dispatch triggers needed
- Release tags always have correct flake hashes
nix run github:TibixDev/winboat/vX.Y.Zworks reliably
Fixes #164 and #177
Looks good to me
Looking at this one (Simon tells me it's still needed, I'm sorry for the delay) - can you please catch up to latest/resolve conflicts and I'll add it to the queue to be looked at for merging - thanks!
flake removed in #434