Macos architecture matching installer

[rainxchzed]

Summary by CodeRabbit

• New Features

  • Apps are now sorted by update availability in the list, placing apps requiring updates prominently.

• Chores

  • Optimized build infrastructure with improved workflow parallelization and artifact compression.
  • Updated desktop package naming convention.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

This pull request optimizes the desktop build workflow by introducing concurrency control, matrix-based macOS builds, and consolidated parallel packaging tasks. It also updates desktop packaging metadata and modifies app list sorting order based on update availability status.

Changes

Cohort / File(s)	Summary
CI/CD Workflow Optimization .github/workflows/build-desktop-platforms.yml	Adds concurrency control; implements matrix-based build strategy for macOS; registers dedicated Gradle setup step with caching across all build jobs; consolidates packaging tasks into parallel invocations (packageExe + packageMsi, packageDmg + packagePkg, packageDeb + packageRpm); adds compression-level: 6 for artifact uploads; introduces per-architecture artifact naming for macOS and Linux.
Build Configuration composeApp/build.gradle.kts	Updates compose.desktop.application.nativeDistributions.packageName from "github-store" to "GitHub-Store".
App Presentation Logic composeApp/src/commonMain/kotlin/zed/rainxch/githubstore/feature/apps/presentation/AppsViewModel.kt	Adds sorting of AppItem list by installedApp.isUpdateAvailable after list construction, ordering apps without updates before those with available updates.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 Our workflows now dance in parallel stride,
With matrices built for the macOS ride,
Apps sorted by updates—a thoughtful touch,
The package name gleams: GitHub-Store, oh so much!
Compression and caching, efficiency's delight! 📦✨

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	You can run @coderabbitai generate docstrings to improve docstring coverage.
Title check	❓ Inconclusive	The title 'Macos architecture matching installer' partially relates to the changes but is overly vague and doesn't clearly convey the main modifications across multiple files.	Consider a more specific title that captures the primary changes, such as 'Optimize macOS builds with matrix strategy and parallel packaging' or similar to better reflect the workflow improvements and package naming changes.

✅ Passed checks (1 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

✨ Finishing touches

• 📝 Generate docstrings

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 0

🧹 Nitpick comments (1)

.github/workflows/build-desktop-platforms.yml (1)

74-82: Consider adding fail-fast: false for independent architecture builds.

The matrix defaults to fail-fast: true, meaning if one architecture fails, the other build is cancelled. For release artifacts, you typically want both builds to complete independently so you can still ship the successful one.

Note: This produces separate architecture-specific installers (macos-installers-x64 and macos-installers-arm64), not a single universal binary. If a true universal binary is desired, an additional step to combine the architectures using lipo would be needed.

🔎 Suggested fix to allow independent builds

   strategy:
+    fail-fast: false
     matrix:
       include:
         - os: macos-13
           arch: x64
         - os: macos-14
           arch: arm64

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 85524d3 and d4b7d8b.

📒 Files selected for processing (3)

• .github/workflows/build-desktop-platforms.yml
• composeApp/build.gradle.kts
• composeApp/src/commonMain/kotlin/zed/rainxch/githubstore/feature/apps/presentation/AppsViewModel.kt

🔇 Additional comments (7)

composeApp/src/commonMain/kotlin/zed/rainxch/githubstore/feature/apps/presentation/AppsViewModel.kt (1)

84-84: Verify the intended sort order for apps with updates.

sortedBy { it.installedApp.isUpdateAvailable } places apps without updates first (since false < true). This pushes apps with available updates to the bottom of the list.

Typically, apps requiring updates should be more prominent to encourage users to update. If the intent is to surface updatable apps first, use sortedByDescending instead:

🔎 Suggested fix if updatable apps should appear first

-                    }.sortedBy { it.installedApp.isUpdateAvailable }
+                    }.sortedByDescending { it.installedApp.isUpdateAvailable }

composeApp/build.gradle.kts (1)

230-230: Consider upgrade path implications from package name change.

Changing packageName from "github-store" to "GitHub-Store" may affect upgrade detection on some platforms. Package managers on case-sensitive systems (macOS, Linux) might treat this as a different application, potentially causing:

• Side-by-side installations instead of upgrades
• Orphaned old installations requiring manual removal

If this is a first release or intentional rebrand, this is acceptable. Otherwise, verify that existing users can upgrade seamlessly.

.github/workflows/build-desktop-platforms.yml (5)

8-10: LGTM!

Concurrency control prevents redundant workflow runs and conserves CI resources when new commits are pushed.

---

27-30: LGTM!

The dedicated Gradle setup action provides better caching than the built-in Java action's Gradle cache, improving build times.

---

60-60: LGTM!

Combining the packaging tasks with --parallel improves build efficiency by running both formats concurrently.

---

133-138: LGTM!

Per-architecture artifact naming (macos-installers-${{ matrix.arch }}) correctly distinguishes the matrix outputs, and compression level 6 provides good size reduction without excessive build time overhead.

---

154-158: LGTM!

The Linux job follows the same patterns established in the Windows and macOS jobs (Gradle setup, parallel packaging, compression level), maintaining consistency across the workflow.

Also applies to: 186-186, 196-197