Skip to content

Conversation

@arkanoider
Copy link
Collaborator

@arkanoider arkanoider commented Oct 23, 2025

Hi @grunch , @AndreaDiazCorreia , @Catrya ,

this morning i spent sometime to improve gh actions to generate mobile desktop versions for:

  • Windows
  • MacOs

the result is here in my fork of mobile, if you want to add this as a feature merge this pr, please consider that I am totally noob on MacOs so I am not aware of the best practise to generate for their MacOs.

Summary by CodeRabbit

  • Chores
    • Added an automated multi-platform build-and-release pipeline for desktop (Linux, macOS, Windows).
    • Pipeline builds, packages platform-specific archives, uploads artifacts, and creates versioned releases using the extracted project version.
    • Supports tag-triggered and manual runs, configurable runtime version, optional analysis, caching, and tolerant matrix behavior to avoid failing all builds.

@grunch
Copy link
Member

grunch commented Oct 23, 2025

great job! can you add linux desktop?

@arkanoider
Copy link
Collaborator Author

great job! can you add linux desktop?

Sorry @grunch was afk! Sure I will add linux desktop asap

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 23, 2025

Walkthrough

Adds a GitHub Actions workflow that builds, packages, and releases Flutter desktop apps for Linux, macOS, and Windows on version tag pushes or manual dispatch; includes SDK setup, dependency installs, build_runner, optional analysis, platform-specific build/packaging, artifact upload, and release creation.

Changes

Cohort / File(s) Summary
CI/CD Workflow Configuration
.github/workflows/desktop.yml
New GitHub Actions workflow "Build Flutter Desktop (Multi-Platform)". Triggers on tag pushes v*.*.* and workflow_dispatch (optional flutter_version). Defines linux/macos/windows matrix, sets up Flutter (stable, configurable version), installs platform deps, accepts licenses non-interactively, caches pub, runs build_runner, extracts version from pubspec.yaml, optionally runs analysis, performs platform-specific release builds, packages outputs into dist/ (tar.gz for Linux, zip for macOS/windows), uploads artifacts, and creates/updates a GitHub Release tagged v{version}. Fail-fast disabled for matrix; some steps use continue-on-error.

Sequence Diagram(s)

sequenceDiagram
    autonumber
    participant Event as Tag Push / Manual
    participant GHA as GitHub Actions
    participant Repo as Repository
    participant SDK as Flutter SDK
    participant Tools as Pub / build_runner
    participant Builder as Platform Build (Linux/macOS/Windows)
    participant Pack as Packager (dist/)
    participant Release as GitHub Release

    Event->>GHA: trigger workflow (tag or dispatch)
    GHA->>Repo: checkout code
    GHA->>SDK: setup Flutter (stable, version)
    GHA->>GHA: accept licenses & cache deps
    GHA->>Tools: install deps, run build_runner
    GHA->>GHA: extract version from pubspec.yaml
    GHA->>GHA: optional code analysis (allowed to fail)
    GHA->>Builder: perform platform-specific release build
    Builder-->>GHA: build artifacts
    GHA->>Pack: package artifacts into dist/ (tar.gz / zip)
    Pack-->>GHA: packaged archives
    GHA->>Release: upload artifacts & create/update release (tag = v{version})
    Release-->>Event: release published
Loading

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 A tag hops in, the runners start,
Builds for desktops play their part,
Linux, Mac, and Windows stride,
Artifacts bundled, version plied,
A release shared — a carrot-crowned heart 🥕

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings)
Check name Status Explanation Resolution
Title Check ⚠️ Warning The pull request title "Creation of desktop application for windows and mac" is misleading and does not accurately capture the main change. The changeset primarily adds a GitHub Actions workflow for building and packaging Flutter desktop applications, not creating the desktop application itself. Additionally, the title omits Linux, which is explicitly included in the workflow implementation (ubuntu-22.04 is part of the matrix build). While the title does reference desktop and platforms that are part of the changes, it obscures the primary purpose (a CI/CD workflow) and is incomplete regarding the full scope of platform coverage. A teammate reviewing the commit history would likely misunderstand that this PR introduces a build automation workflow rather than application code. Consider revising the title to accurately reflect that this PR adds a GitHub Actions workflow for building multi-platform desktop applications. A more appropriate title might be "Add GitHub Actions workflow for building Flutter desktop for Windows, macOS, and Linux" or "Add multi-platform desktop build and release workflow". This would clearly communicate that the change is about build automation and include all supported platforms, making the intent immediately clear to reviewers and future readers of the commit history.
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.
✅ Passed checks (1 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
✨ Finishing touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (1)
.github/workflows/linux.yml (1)

24-28: Consider pinning Linux build dependency versions for reproducibility.

The Linux dependencies are installed without version constraints using apt-get, which means builds may differ over time as packages update. While this ensures compatibility with latest patches, it can also introduce non-deterministic behavior. For CI/CD reliability, consider pinning dependency versions or explicitly documenting that latest versions are acceptable.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1ba5ce0 and b119659.

📒 Files selected for processing (3)
  • .github/workflows/MacOs.yml (1 hunks)
  • .github/workflows/linux.yml (1 hunks)
  • .github/workflows/windows.yml (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build
🔇 Additional comments (3)
.github/workflows/MacOs.yml (1)

38-50: Version extraction and artifact naming — verify cross-platform consistency with Windows implementation.

The version extraction logic correctly uses grep with anchored pattern and removes carriage returns for cross-platform compatibility. Both $GITHUB_ENV and $GITHUB_OUTPUT are set properly for downstream step references. Ensure the Windows workflow's different extraction approach (PowerShell) produces identical version strings.

.github/workflows/windows.yml (2)

30-35: Verify or refactor the Android license acceptance command.

The PowerShell syntax "y" * 100 creates a string of 100 consecutive 'y' characters, which may not function as intended for interactive license prompts that expect separate responses per agreement. Since the step has continue-on-error: true, build failures here won't block the workflow.

Consider: (1) verifying this command actually works as intended; (2) removing it if Android SDK licenses aren't needed for Windows desktop builds; or (3) using a more explicit PowerShell approach to handle interactive prompts.


45-54: Verify Windows version extraction produces identical output to Unix implementations.

The Windows PowerShell version extraction uses a different approach than the bash scripts in macOS and Linux workflows:

  • Unix (MacOs.yml, linux.yml): grep '^version: ' pubspec.yaml | cut -d ' ' -f 2 | tr -d '\r'
  • Windows (this file): (Select-String -Path pubspec.yaml -Pattern '^version: ').Line -replace 'version: ','' | Trim()

While both are platform-appropriate, they must produce identical version strings for consistent release tagging. Edge cases like trailing whitespace or line endings could cause mismatches. Verify the extracted versions are identical across platforms, especially if pubspec.yaml has non-standard formatting.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (1)
.github/workflows/desktop.yml (1)

41-45: Consider making Flutter version configurable and add dependency caching.

The hardcoded Flutter version (3.32.2) reduces flexibility for testing with newer versions. Additionally, there's no caching of Flutter or pub dependencies, which adds build time overhead on every run.

Apply this diff to add caching and make the version configurable:

       - name: Setup Flutter
         uses: subosito/flutter-action@v2
         with:
           channel: stable
-          flutter-version: '3.32.2'
+          flutter-version: '3.32.2'  # Set to 'stable' or use a workflow input for flexibility
+      
+      - name: Cache Flutter dependencies
+        uses: actions/cache@v4
+        with:
+          path: ~/.pub-cache
+          key: ${{ runner.os }}-pub-${{ hashFiles('**/pubspec.lock') }}
+          restore-keys: ${{ runner.os }}-pub-

Optionally, consider using a workflow input for version:

on:
  push:
    tags: ['v*.*.*']
  workflow_dispatch:
    inputs:
      flutter-version:
        description: 'Flutter version (default: 3.32.2)'
        required: false
        default: '3.32.2'

Then in the Setup Flutter step:

           flutter-version: ${{ github.event.inputs.flutter-version || '3.32.2' }}
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b119659 and c7df704.

📒 Files selected for processing (1)
  • .github/workflows/desktop.yml (1 hunks)
🔇 Additional comments (2)
.github/workflows/desktop.yml (2)

121-136: Ensure artifact paths are consistent between creation and upload.

The artifact upload step (line 126) searches for files at a relative path that depends on the current working directory. After the packaging steps create files with cd and ../../../../../ navigation, the path reference in line 126 may not resolve correctly.

This issue is resolved by the packaging refactor suggested in the previous comment. Verify that the dist directory path is used consistently in both packaging and upload steps.


1-137: Based on the verification conducted, I found a valid concern about workflow duplication. Matrix workflows eliminate separate jobs for each configuration by defining them all in one place, making workflow files cleaner and easier to read while simplifying maintenance. The script confirmed that separate platform-specific workflows (macos.yml, linux.yml, windows.yml) exist alongside the new multi-platform desktop.yml.

However, without access to documentation about the repository's CI/CD consolidation strategy, trigger conditions for each workflow, or maintenance status of the older files, I cannot definitively determine whether this represents an active maintenance burden or a transitional deprecation.

Clarify the intended CI/CD workflow strategy and deprecation timeline for platform-specific workflows.

Before merging this multi-platform desktop.yml workflow, document whether the existing platform-specific workflows (macos.yml, linux.yml, windows.yml) should be:

  • Deprecated and removed after this workflow is stable
  • Maintained in parallel for different purposes (clarify why)
  • Already replaced but not yet cleaned up

Having multiple workflows for the same purpose leads to maintenance challenges; a unified matrix approach simplifies modifications since updates only need to occur in one workflow configuration. If both approaches will coexist, ensure they remain synchronized and document the division of responsibilities.

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between d99b7ff and d8642f4.

📒 Files selected for processing (1)
  • .github/workflows/desktop.yml (1 hunks)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: build
🔇 Additional comments (1)
.github/workflows/desktop.yml (1)

107-118: ✅ Version extraction validation addressed previous concern.

The addition of the version check (lines 112-114) correctly prevents silent failures when version extraction fails. Good defensive programming.

Copy link
Member

@grunch grunch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@grunch grunch merged commit c827083 into MostroP2P:main Oct 23, 2025
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants