Update deploy-android-to-play-store.yml #2360
Conversation
📝 WalkthroughWalkthroughThe pull request involves updating the GitHub Actions workflow for Android deployment to the Play Store. The primary change is specifying the Ubuntu runner version as Changes
Suggested labels
Suggested reviewers
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🔭 Outside diff range comments (1)
.github/workflows/deploy-android-to-play-store.yml (1)
Release notes handling needs improvement
The current implementation has a few concerns:
- The Play Store deployment (
play_storelane) doesn't utilize release notes at all, while the Firebase distribution lane does use them- The hardcoded version "3.0.2" in the default release notes doesn't align with the dynamic build number generation in the Fastfile
- The release notes file is being created in a different location than where the Firebase distribution lane expects it
Suggested improvements:
- Either remove the release notes handling for Play Store deployment if not needed, or
- Implement proper release notes handling that aligns with the dynamic version numbering
- Ensure consistent file paths between creation and usage
🔗 Analysis chain
Line range hint
71-93: Verify the release notes handlingThe current implementation creates default release notes if
release_notes.txtdoesn't exist. This could potentially lead to deploying with generic notes ("App release version 3.0.2").Let's check if there are any existing patterns for release notes:
Let me check the content of the Fastfile to understand the release notes handling pattern better.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for release notes patterns in the repository rg -g '!node_modules' -g '!build' -g '!dist' "release.*notes" -l # Check for version number patterns rg -g '!node_modules' -g '!build' -g '!dist' "version.*[0-9]+\.[0-9]+\.[0-9]+" -lLength of output: 1322
Script:
#!/bin/bash # Check the content of the Fastfile for release notes handling cat mobile-v3/android/fastlane/Fastfile # Also check if there's an existing release_notes.txt fd release_notes.txtLength of output: 1618
🧹 Nitpick comments (1)
.github/workflows/deploy-android-to-play-store.yml (1)
Line range hint
1-93: Consider enhancing the workflow's security and maintainabilityWhile the workflow is functional, here are some suggestions to improve its security and maintainability:
- Add timeouts to prevent long-running workflows:
jobs: android: name: android build runs-on: ubuntu-22.04 + timeout-minutes: 60
Consider using reusable workflows for the setup steps (JDK, Flutter, Cloud SDK) to maintain consistency across different workflows.
Add environment protection rules for the secrets being used.
Consider adding a manual approval step before the actual deployment to Play Store.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/deploy-android-to-play-store.yml(1 hunks)
🔇 Additional comments (1)
.github/workflows/deploy-android-to-play-store.yml (1)
14-14: Good choice on pinning the Ubuntu runner version!
Using ubuntu-22.04 instead of ubuntu-latest is a solid improvement that provides better stability and predictability for the CI/CD pipeline. This prevents unexpected breaks that could occur when latest automatically updates to a newer version.
|
@Baalmart merge this into staging |
Summary of Changes (What does this PR do?)
Status of maturity (all need to be checked before merging):
How should this be manually tested?
What are the relevant tickets?
Screenshots (optional)
Summary by CodeRabbit