ci: windows arm build

[0xbrayo]

Important

Add Windows ARM64 build support to build.yml and release.yml workflows.

• Workflows:
  • Add Windows ARM64 build support in build.yml and release.yml.
  • Add platform entry windows-latest with --target aarch64-pc-windows-msvc argument for Windows ARM64.

^{This description was created by for ff526a9. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to ff526a9 in 1 minute and 16 seconds

More details

• Looked at 26 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 4 drafted comments based on config settings.

1. .github/workflows/build.yml:21

• Draft comment:
  Consider using a unique identifier (e.g. 'windows-arm64') for the ARM build entry to differentiate it from the standard Windows build.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50%
  The current setup uses the same platform identifier 'windows-latest' twice, but differentiates the ARM build using the args parameter. While using a unique identifier might make the configuration more readable, the current setup is functionally correct since GitHub Actions matrices can handle this pattern. The args parameter already clearly identifies the ARM target.
  The current setup might actually be intentional to ensure both builds use the same Windows runner environment. A different identifier might imply a different runner type.
  While the suggestion might improve readability, it's not clearly incorrect or problematic as is, and the current approach might be deliberately chosen to ensure consistent runner environments.
  This comment should be deleted as it suggests a change that isn't clearly necessary or beneficial, and the current implementation is functionally correct.

2. .github/workflows/release.yml:22

• Draft comment:
  Consider using a unique identifier (e.g. 'windows-arm64') for the ARM build entry to avoid confusion with standard Windows builds.
• Reason this comment was not posted:
  Marked as duplicate.

3. .github/workflows/build.yml:21

• Draft comment:
  Consider adding an explicit identifier (e.g. an 'arch' field) in the matrix for Windows ARM64 to differentiate it from the default 'windows-latest' entry.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. .github/workflows/release.yml:21

• Draft comment:
  Consider differentiating the Windows ARM64 entry (e.g. by adding an 'arch' field) to clarify its purpose versus the default Windows build.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

Workflow ID: wflow_OwhaDZWI5YgC47KU

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[TimeToBuildBob]

Hey @0xbrayo! A few things I noticed that might help get this merged:

1. Build vs Release workflow inconsistency: build.yml uses platform: 'windows-11-arm' (correct — native ARM runner), but release.yml uses platform: 'windows-latest' for the aarch64-pc-windows-msvc target. That means the release build would try to cross-compile on an x64 runner, which likely won't produce correct artifacts. Should use windows-11-arm in both places.

2. CI failure: The release (windows-11-arm, ...) job failed but the logs have expired. Worth pushing a small fixup or re-triggering CI to get fresh logs — could be missing ARM64 deps on the runner image, or Tauri's native WebView2 dependencies not being available for ARM64.

3. Minor nits:

   • Extra space before colon in build.yml: if : matrix.args != null → if: matrix.args != null
   • The gptme.toml addition seems unrelated to CI changes — might want to drop it or split to a separate PR
   • Commit messages could use cleanup on squash-merge

The actual change is small and clean though — getting ARM64 builds working would be great for the aw-tauri release. Happy to help investigate the CI failure if you'd like!

[0xbrayo]

@TimeToBuildBob push a commit with your recommendations and check the CI logs after.

[TimeToBuildBob]

@0xbrayo I don't have push access to your fork, so I've pushed the fixes to my fork: TimeToBuildBob/aw-tauri:aarch64 (commit 4dcbb26).

You can cherry-pick it:

git remote add bob https://github.com/TimeToBuildBob/aw-tauri.git
git fetch bob aarch64
git cherry-pick 4dcbb26

Changes made:

1. release.yml: Wrong runner — windows-latest → windows-11-arm

   • Was trying to cross-compile on an x64 runner. Should use the native ARM runner (matching build.yml).

2. release.yml: Missing "Add rust target" step

   • build.yml had this step but release.yml didn't. Without it, the ARM target isn't installed and the build fails.

3. build.yml: Extra space in if condition — if : → if:

4. Removed gptme.toml — unrelated to CI changes, shouldn't be in this PR.

Let me know if you'd prefer I open a separate PR instead!

[TimeToBuildBob]

Pushed fixes as a separate PR: #202

• Fixed if : → if: in build.yml
• Fixed release.yml to use windows-11-arm instead of windows-latest for the ARM64 target
• Added missing rustup target add step to release.yml
• Removed unrelated gptme.toml file

You can either review and merge #202, or cherry-pick the commit into your branch.

[0xbrayo]

@TimeToBuildBob look at the logs, there are crates that are not arm compatible on windows, suggest fixes.

[TimeToBuildBob]

Windows ARM64 CI failure analysis

I looked at the CI logs. The build fails with 285 errors in winapi v0.2.8, which predates ARM64 Windows support entirely.

The types ULONG_PTR, LONG_PTR, UINT_PTR, size_t are defined in winapi 0.2.8 only for x86 and x86_64 — no aarch64 branch exists. So every downstream user of these types fails to compile for aarch64-pc-windows-msvc.

Identifying the root cause

Run this to find what pulls in winapi 0.2.x:
```bash
cargo tree -i winapi:0.2 --target aarch64-pc-windows-msvc
```

Likely suspects based on the dependency tree in the build logs: something depending on an old version of rocket or another crate with stale Windows deps.

Fix options

Option 1 (preferred): Upgrade the parent dependency
Find the crate that requires winapi = "0.2" and check if a newer version of that crate uses winapi = "0.3" (which has ARM64 support).

Option 2: Cargo.toml patch
Add to Cargo.toml:
```toml
[patch.crates-io]

Stub out winapi 0.2.x for ARM64 (if direct upgrade is not possible)

```
This approach is complex — winapi 0.2.x is API-incompatible with 0.3.x, so a simple patch won't work without a shim.

Option 3: Exclude from ARM64 CI temporarily
If the dependency is optional (e.g. for a non-critical feature), you can gate it with #[cfg(not(target_arch = "aarch64"))] or a feature flag.

The most actionable next step is running cargo tree -i winapi:0.2 to identify which specific crate version to upgrade.

[0xbrayo]

appdirs which hasn't been updated since 2016 is the culprit. There are multiple options to choose from directories, dirs and etcetera. Which one who would be the best for this case. @TimeToBuildBob make sure to check how appdirs is used both in aw-tauri and aw-server-rust.

[TimeToBuildBob]

Checked both aw-tauri and aw-server-rust — here's a complete picture:

How appdirs is used

Both codebases use identical patterns:

// get config dir (aw-tauri/src-tauri/src/dirs.rs and aw-server-rust/aw-server/src/dirs.rs)
let mut dir = appdirs::user_config_dir(Some("activitywatch"), None, false)?;
dir.push("aw-tauri");  // or "aw-server-rust"

// get data dir (same pattern)
let mut dir = appdirs::user_data_dir(Some("activitywatch"), None, false)?;
dir.push("aw-tauri");

aw-sync/src/dirs.rs also uses appdirs::user_config_dir but notably already imports dirs::home_dir — so dirs is already a partial dependency there.

Recommendation: directories crate

directories is the best drop-in because it was designed as a modern, maintained replacement for appdirs-style APIs:

directories = "5"

use directories::ProjectDirs;

pub fn get_config_dir() -> Result<PathBuf, ()> {
    let proj = ProjectDirs::from("", "activitywatch", "activitywatch").ok_or(())?;
    let dir = proj.config_dir().join("aw-tauri");  // ~/.config/activitywatch/aw-tauri
    fs::create_dir_all(&dir).expect("Unable to create config dir");
    Ok(dir)
}

This preserves the existing path structure (~/.config/activitywatch/aw-tauri on Linux, %APPDATA%\activitywatch\aw-tauri on Windows) for backward compatibility.

Why not dirs?

dirs works and aw-sync already uses it, but it doesn't have org/project scoping. You'd write dirs::config_dir().join("activitywatch").join("aw-tauri") — equivalent but less semantic than directories.

Scope of the change

• aw-tauri: src-tauri/Cargo.toml + src-tauri/src/dirs.rs (4 call sites)
• aw-server-rust: aw-server/Cargo.toml + aw-server/src/dirs.rs + aw-sync/Cargo.toml + aw-sync/src/dirs.rs (small, ~6 call sites total)

Happy to draft the code change for both if that's useful.

[TimeToBuildBob]

Created the aw-server-rust fix: ActivityWatch/aw-server-rust#562

This replaces appdirs with dirs in aw-server, aw-sync, and aw-datastore. Also updated PR #202 (my CI config fixes PR) to temporarily point at the fix branch so the Windows ARM64 build can be validated end-to-end.

Once ActivityWatch/aw-server-rust#562 is merged, PR #202 will be updated to point back to ActivityWatch/aw-server-rust:master and should pass CI cleanly.

[TimeToBuildBob]

Update: ActivityWatch/aw-server-rust#562 now has all 7 CI checks green (format, clippy, ubuntu, macOS, windows, Android, coverage). The fixes applied:

• Bumped dirs from "5" to "6" across all Cargo.toml files
• Removed conflicting extern crate dirs; from lib.rs
• Fixed cargo fmt formatting in method chains

Once #562 is merged into ActivityWatch/aw-server-rust master, #202 can be rebased to point at the upstream master dep and should build cleanly.