chore: Added app builds for Windows, macOS, Linux#217
chore: Added app builds for Windows, macOS, Linux#217Vishveshwara wants to merge 9 commits intofossasia:mainfrom
Conversation
Reviewer's GuideThis PR extends both push and pull_request GitHub workflows to support cross-platform Flutter builds for Windows, macOS, Debian, and Web by introducing new CI jobs, composite actions for each platform, artifact uploads, and automated publishing to the 'app' branch. Flow diagram for new build and publish process for each platformflowchart TD
checkout["Checkout Source Code"] --> setup_flutter["Set up Flutter"]
setup_flutter --> build_app["Build App (platform-specific)"]
build_app --> upload_artifact["Upload Build Artifact"]
upload_artifact --> push_app_branch["Push Build to 'app' branch"]
File-Level Changes
Possibly linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
Blocking issues:
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
- An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload. (link)
General comments:
- Extract the repeated “Push Build to app branch” shell logic into a reusable composite action or step to reduce duplication across all platforms.
- The Web build job’s push step is missing the final
git push --force origin app—add it to keep consistency with the other platform workflows. - Consider using a matrix strategy for your per-platform jobs instead of copying identical steps to DRY up the workflow file.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Extract the repeated “Push Build to app branch” shell logic into a reusable composite action or step to reduce duplication across all platforms.
- The Web build job’s push step is missing the final `git push --force origin app`—add it to keep consistency with the other platform workflows.
- Consider using a matrix strategy for your per-platform jobs instead of copying identical steps to DRY up the workflow file.
## Security Issues
### Issue 1
<location> `.github/actions/debian/action.yml:17` </location>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Issue 2
<location> `.github/actions/macos/action.yml:17` </location>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Issue 3
<location> `.github/actions/web/action.yml:17` </location>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>
### Issue 4
<location> `.github/actions/windows/action.yml:17` </location>
<issue_to_address>
**security (yaml.github-actions.security.third-party-action-not-pinned-to-commit-sha):** An action sourced from a third-party repository on GitHub is not pinned to a full length commit SHA. Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.
*Source: opengrep*
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Build StatusBuild successful. APKs to test: https://github.com/fossasia/magic-epaper-app/actions/runs/21834993053/artifacts/5435913688. ScreenshotsAndroid Screenshots
iPhone Screenshots
iPad Screenshots
|
-1_display_selection.png?raw=true)
-2_sidebar.png?raw=true)
-3_ndef_screen.png?raw=true)
-4_filter_selection.png?raw=true)
-5_barcode_screen.png?raw=true)
-6_Barcode_added.png?raw=true)
-7_Templates_screen.png?raw=true)
AsCress
left a comment
AsCress
left a comment
There was a problem hiding this comment.
We shouldn't just plainly push the files to the app branch. We should instead package them into installers and then push them.
See for example, in Windows: fossasia/pslab-app#2896.
You can figure out similarly for Linux packages (.deb, .rpm). For macOS, pushing the .app should be enough.
Oh okay will do it, thanks. |
Vishveshwara
changed the title
|
@Dhruv1797 please test this, thank you |
There was a problem hiding this comment.
Pull request overview
This PR extends the repository’s GitHub Actions CI to produce desktop build artifacts (Linux, macOS, Windows) for the Flutter app and adjusts macOS project settings to match the new macOS build requirements, aligning with issue #181’s request for automated multi-platform builds.
Changes:
- Add composite GitHub Actions for Linux, macOS, and Windows Flutter builds.
- Extend
pushandpull_requestworkflows with new Linux/macOS/Windows build jobs and artifact publishing. - Raise macOS deployment target to 11.0 in Xcode project and CocoaPods configuration.
Reviewed changes
Copilot reviewed 7 out of 7 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
macos/Runner.xcodeproj/project.pbxproj |
Bumps macOS deployment target to 11.0 to support CI macOS builds. |
macos/Podfile |
Aligns CocoaPods platform version with macOS 11.0 deployment target. |
.github/workflows/push.yml |
Adds Linux/macOS/Windows build jobs and publishes artifacts to the app branch. |
.github/workflows/pull_request.yml |
Adds Linux/macOS/Windows build jobs for PR validation. |
.github/actions/linux/action.yml |
New composite action to build Linux and package .deb/.rpm artifacts. |
.github/actions/macos/action.yml |
New composite action to build macOS app and upload artifact. |
.github/actions/windows/action.yml |
New composite action to build Windows app. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Push macOS Build to app branch | ||
| shell: bash | ||
| run: | | ||
| git config --global user.name "github-actions[bot]" | ||
| git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" |
There was a problem hiding this comment.
The macOS job’s push-to-app step is missing the if: github.repository == 'fossasia/magic-epaper-app' guard used elsewhere. In forks, this will fail due to missing push permissions and can make the push workflow red for external contributors. Add the same repository guard (or otherwise skip publishing) for the macOS publish step.
| - name: Upload packages to app branch | ||
| if: ${{ github.repository == 'fossasia/magic-epaper-app' }} | ||
| run: | | ||
| git config --global user.name "github-actions[bot]" | ||
| git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" |
There was a problem hiding this comment.
This workflow now has multiple jobs force-pushing to the same app branch (Android + Linux/macOS/Windows). Because each job clones app and then rewrites it with git push --force, whichever job finishes last can overwrite artifacts pushed by the others. Consider serializing publishing (single job that needs all builds and pushes once) or coordinating updates so they don’t race.
|
|
||
| echo "Copying new build files" | ||
|
|
||
| cp -v ../build/windows/x64/installer/Release/*.exe . |
There was a problem hiding this comment.
The Windows job copies ../build/windows/x64/installer/Release/*.exe to publish to the app branch, but the Windows composite action only runs flutter build windows and this repository has no other references that produce an installer/Release output directory. This cp is likely to fail at runtime. Either add an explicit installer-packaging step that produces that path, or adjust the copy path to match Flutter’s actual build output for Windows.
| cp -v ../build/windows/x64/installer/Release/*.exe . | |
| cp -v ../build/windows/x64/runner/Release/*.exe . |
| git checkout --orphan temporary | ||
| git add --all | ||
| git commit -m "[Auto] Update macOS build from $branch ($(date +%Y-%m-%d.%H:%M:%S))" | ||
| git branch -D app | ||
| git branch -m app |
There was a problem hiding this comment.
This git checkout --orphan + force-push publish pattern is vulnerable to races with the other platform jobs that also force-push to app. The last job to push wins, potentially dropping artifacts from other platforms. Recommend moving all app publishing into a single downstream job that depends on all builds and publishes artifacts in one push.
| # Copy all macOS build artifacts to root | ||
| cp -r ../build/macos/Build/Products/Release/* . |
There was a problem hiding this comment.
The macOS build artifacts are copied into the root of the app branch without cleaning/replacing a dedicated macOS directory first. Over time this can leave stale files (e.g., if the set of outputs changes between builds) and makes it hard to tell which files belong to which platform. Consider publishing into a platform-specific directory (e.g., macos/) and deleting/replacing just that directory before committing.
| # Copy all macOS build artifacts to root | |
| cp -r ../build/macos/Build/Products/Release/* . | |
| # Copy all macOS build artifacts into a dedicated macos/ directory | |
| mkdir -p macos | |
| rm -rf macos/* | |
| cp -r ../build/macos/Build/Products/Release/* macos/ |
| git checkout --orphan temporary | ||
| git add --all . | ||
| git commit -am "[Auto] Update Windows Installer's from $branch ($(date +%Y-%m-%d.%H:%M:%S))" | ||
| git branch -D app | ||
| git branch -m app |
There was a problem hiding this comment.
This Windows publish step force-pushes to the shared app branch, which can race with the Android/Linux/macOS publish steps that also rewrite app. Depending on timing, this can overwrite/destroy artifacts produced by the other jobs. Consider a single publish job after all builds, or otherwise serialize app updates.
| macos: | ||
| name: macOS Flutter Build | ||
| needs: common | ||
| runs-on: macos-latest | ||
| steps: |
There was a problem hiding this comment.
The PR description/Sourcery summary mentions adding Web builds/composite actions, but there is no web job/action added in this PR (repo search shows no Web workflow/action). Either add the missing Web build pipeline or update the PR description to match the actual scope.
Fixes: #181
Summary by Sourcery
Add CI pipelines to build and deploy Flutter app for Debian, macOS, Windows, and Web platforms
New Features:
Enhancements:
CI:
appbranch