refactor(ci): unify build and release workflows

[TimeToBuildBob]

Summary

• replace the split dev-release.yml, build.yml, and build-tauri.yml workflows with a single release.yml
• keep the current dev prerelease preflight/tagging logic, including exact-SHA tagging and self-exclusion of the current workflow run
• build Qt and Tauri artifacts from one workflow file and publish one combined draft GitHub release on tag pushes

Testing

• parsed .github/workflows/release.yml with python3 + yaml.safe_load
• ran git diff --check
• verified current release assets already use distinct activitywatch-... and activitywatch-tauri-... names, so the combined release upload set is collision-safe

Refs #1219

[TimeToBuildBob]

Rebased this draft PR on bf66fa6 and force-pushed 503830d.

Conflict resolution: the three old workflow files are still intentionally deleted, and I ported the new upstream workflow fixes into .github/workflows/release.yml instead: higher prerelease-line continuation, auxiliary-check filtering, version diagnostics, WebKit pin / Tauri Linux artifacts, macOS artifact naming, and the action version bumps.

Local validation: yaml.safe_load on release.yml passes, and git diff --check upstream/master...HEAD is clean. GitHub now reports the PR as mergeable; CI is pending on the new head.

[greptile-apps]

Greptile Summary

This PR replaces three separate workflow files (build.yml, build-tauri.yml, dev-release.yml) with a single release.yml that consolidates the Qt build matrix, Tauri build matrix, biweekly dev-prerelease scheduling, and the unified draft GitHub release into one file. The logic from all three source files is faithfully preserved, and a pre-existing typo (steps.version.output.is_stable) is also fixed.

• Unified release job publishes one combined draft release on tag pushes, replacing the two previously independent release jobs — but now any single platform failure in either of the 9 build matrix jobs blocks the entire release.
• macOS DMG naming: Both build-qt and build-tauri have identical Package dmg steps that rename the output to activitywatch-${VERSION_TAG}-macos-x86_64.dmg; if the Tauri path ever produces this file, two assets with the same basename will collide on upload to the single GitHub release.

Confidence Score: 3/5

Safe to merge for CI/build runs, but the combined release publish path has an unverified macOS artifact naming assumption that could cause the first real tag release to fail.

The dev-prerelease and build paths work correctly as migrated. The concern is the release job: both build-qt and build-tauri contain identical Package dmg steps that produce the same output filename, and if the Tauri macOS build ever reaches that step (which depends on Makefile behavior not visible here), softprops/action-gh-release would see duplicate basenames in the upload set and the release publish would fail or lose an asset.

.github/workflows/release.yml — specifically the Package dmg steps in both build-qt (line 333) and build-tauri (line 513), and the release job's combined artifact upload (line 614).

Important Files Changed

Filename	Overview
.github/workflows/release.yml	New unified workflow file combining preflight/tag, Qt build, Tauri build, release-notes, and publish jobs. Contains a macOS DMG filename collision risk and a changed failure-coupling model for the combined release job.
.github/workflows/build.yml	Deleted — Qt build and release logic fully migrated to release.yml with content faithfully preserved.
.github/workflows/build-tauri.yml	Deleted — Tauri build and release logic fully migrated to release.yml with content faithfully preserved.
.github/workflows/dev-release.yml	Deleted — dev prerelease preflight/tag logic faithfully migrated to release.yml, including biweekly cadence check, exact-SHA checkout, and check-suite self-exclusion.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    E1([schedule / workflow_dispatch]) --> preflight
    E2([push to master or v* tag]) --> build-qt
    E2 --> build-tauri
    E3([pull_request to master]) --> build-qt
    E3 --> build-tauri
    preflight{Pre-flight checks} -->|should_release=true| create-tag
    create-tag -->|pushes v* tag via PAT → new run| E2
    E2 -->|tag push only| release-notes
    build-qt -->|tag push only| release
    build-tauri -->|tag push only| release
    release-notes -->|tag push only| release
    release([Publish draft GitHub release])
    style preflight fill:#f0e68c
    style create-tag fill:#f0e68c
    style release fill:#90EE90

Loading

_{Reviews (1): Last reviewed commit: "refactor(ci): unify release workflows" | Re-trigger Greptile}

[greptile-apps]

macOS DMG filename collision in unified release

Both build-qt (line 352) and build-tauri (line 532) rename their macOS output to the identical pattern activitywatch-${VERSION_TAG:-...}-macos-x86_64.dmg. They are uploaded to different artifact containers (builds-macos-14-py3.9 vs builds-tauri-macos-14-py3.9), but when the release job's dist/*/activitywatch-*.* glob collects them both, softprops/action-gh-release@v2 will attempt to upload two assets with the same basename to a single GitHub release, which will either error out or silently overwrite one. The PR description claims distinctness via a activitywatch-tauri-… prefix, but the actual mv command in build-tauri's "Package dmg" step (line 532) produces the same name as build-qt's. If the Makefile or Tauri packaging path never actually creates dist/ActivityWatch.dmg when TAURI_BUILD=true, the step is dead code and the collision never occurs — but that assumption is invisible from the workflow file alone and should be made explicit.

[TimeToBuildBob]

The DMG names are already distinct at the actual command. Qt produces activitywatch-${VERSION_WITH_V}-macos-$(uname -m).dmg (line 385) and Tauri produces activitywatch-tauri-${VERSION_WITH_V}-macos-$(uname -m).dmg (line 603). The tauri- prefix is present in the final rename — so when the release job's glob collects both artifact sets, the basenames are distinct and softprops/action-gh-release won't see a collision.

Two other corrections on the review's framing: the variable is VERSION_WITH_V (not VERSION_TAG), and the architecture suffix is dynamic ($(uname -m)) rather than hardcoded to x86_64.

[greptile-apps]

Single platform failure in either matrix blocks the entire combined release

In the old split design, build.yml and build-tauri.yml each had independent release jobs, so a flaky Tauri build on one platform only blocked the Tauri release while Qt artifacts were still published. With needs: [build-qt, build-tauri, release-notes], a single flaky matrix run in either of the 9 total build jobs (4 Qt + 5 Tauri) now blocks publishing any artifacts at all. If build-tauri's ubuntu-24.04-arm job is unstable, the combined release will never be published. Consider whether continue-on-error at the matrix level or a separate release step per build group better matches the desired failure semantics.

[TimeToBuildBob]

Acknowledged — this is an intentional trade-off. The old split design did mean a flaky Tauri platform left Qt artifacts publishable independently, so the combined needs: [build-qt, build-tauri, release-notes] gate does tighten the coupling.

The rationale for accepting it: real tag releases are rare, manual, and happen on a stable commit — transient flakiness is less likely to bite there than on the dev-prerelease path (which this workflow also handles). If the arm64 or other Tauri job proves unstable in practice, adding continue-on-error: true at the matrix level or splitting into per-group release steps is a straightforward follow-up. Leaving this note here so the trade-off is visible to reviewers.