fix(ci) : Build and deploy workflow #581
Conversation
Signed-off-by: Ujwal Akotkar <[email protected]>
|
🎉 Welcome @uju09!
We appreciate your contribution! 🚀 |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughReplaces the previous CI workflow with a single GitHub Actions workflow that builds an Android App Bundle (AAB), decodes signing/service secrets, runs tests, and creates a GitHub Release using the AAB; adds Java/Android/Flutter setup and environment/dart-define configuration. (50 words) Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Push as Push event (main/master/deploy-actions)
participant Repo as Checkout repo
participant Setup as Setup Java/Android SDK/Flutter
participant Secrets as Decode secrets to workspace
participant Test as Run flutter tests
participant Build as Build AAB (flutter build appbundle)
participant Verify as Verify AAB exists
participant Upload as Upload AAB artifact
participant Release as Create GitHub Release (attach AAB)
Push->>Repo: trigger workflow
Repo->>Setup: install Java, Android SDK, Flutter (+ cache)
Setup->>Secrets: write keystore, keyprops, google-services, firebase files
Secrets->>Test: run `flutter test`
Test->>Build: build appbundle with dart-defines
Build->>Verify: check AAB path
Verify->>Upload: upload `aab-release`
Upload->>Release: create GitHub Release with AAB artifact
Release-->>Push: workflow complete
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Possibly related PRs
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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. Comment |
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
![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
🧹 Nitpick comments (2)
.github/workflows/build_and_deploy.yml (2)
16-28: Consider not exposing secrets as environment variables.Line 28 exposes
APPWRITE_PROJECT_IDas an environment variable from secrets. While GitHub Actions automatically redacts known secrets in logs, best practice is to pass secrets directly to steps that need them rather than storing them in environment variables, reducing the risk of accidental exposure through logs, artifacts, or subprocesses.Since this value is already used in the build step (line 83), consider passing it inline there instead of exposing it as an environment variable.
93-100: Consider extracting hardcoded package name to environment variable.The package name
com.resonate.resonateis hardcoded in the Play Store deployment step. For maintainability and to prevent inconsistencies, consider moving this to an environment variable at the top of the workflow (similar to howAAB_PATHand other paths are defined).This makes future package name changes easier and ensures consistency across the workflow.
# Add to env section (after line 27): PACKAGE_NAME: com.resonate.resonate- name: Deploy to Play Store (Internal testing) uses: r0adkll/upload-google-play@v1 with: serviceAccountJson: ${{ env.SERVICE_ACCOUNT_PATH }} - packageName: com.resonate.resonate + packageName: ${{ env.PACKAGE_NAME }} releaseFiles: ${{ env.AAB_PATH }} track: internal
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build_and_deploy.yml(1 hunks)
🔇 Additional comments (5)
.github/workflows/build_and_deploy.yml (5)
4-10: Verify workflow trigger configuration.The current trigger configuration removes
pull_requestandworkflow_dispatchevents (if they existed before), meaning this workflow won't run on pull requests or be manually triggered. This may limit testing and validation capabilities. The addition of thedeploy-actionsbranch as a trigger is non-standard.Please confirm this trigger configuration aligns with your CI/CD strategy. If you want developers to validate the workflow on PRs or manually trigger deployments, consider adding back
pull_request(with appropriate guards) andworkflow_dispatchtriggers.
30-49: Setup steps are well-configured.The checkout, Java, Android SDK, and Flutter setup steps follow best practices with appropriate version pinning, explicit distribution selection, and caching enabled for Flutter.
51-70: Secret decoding is well-structured and secure.The base64 decoding steps correctly handle all required secrets with consistent patterns. The use of environment variables for paths ensures maintainability, and temporary file creation in the workflow workspace is appropriate.
72-91: Build and test configuration is solid.The addition of the test step before building the AAB is a best practice that ensures code quality. The AAB build with appropriate dart-define parameters and release flag is correct for production deployments.
103-112: Verify GitHub Release artifact content type and clarify release strategy.Two concerns on the GitHub Release deployment:
Line 109 –
artifactContentType: aabmay not be recognized. Standard MIME types for AAB files areapplication/octet-streamorapplication/x-aab. Verify thataabis a valid value for this action or update to a standard MIME type.Line 111 – Using
tag: latest_buildmeans each build overwrites the previous release. Confirm this is your intended behavior. If you want to preserve build history, consider using a versioned tag (e.g.,tag: build-${{ github.run_number }}).Line 107 – The comment "This will find the .aab file in the release directory" is misleading; the path is defined by the
AAB_PATHenvironment variable, not auto-discovered.
|
@M4dhav Can u test this workflow on a test branch? |
|
Or any changes are needed? |
|
Hey @uju09 this workflow will only build and deploy to GitHub releases. Remove the Google Play related code |
|
@M4dhav Ok, I will remove it, but it was mentioned in the issue, so I added. 
|
Signed-off-by: uju09 <[email protected]>
Signed-off-by: uju09 <[email protected]>
Signed-off-by: uju09 <[email protected]>
|
@CodeRabbit review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/build_and_deploy.yml (1)
68-72: Simplify redundant APPWRITE_PROJECT_ID definition.Line 25 sets
APPWRITE_PROJECT_IDas an environment variable from the secret, but it's only used as a dart-define on line 72. You can simplify this by removing the env variable declaration (line 25) and directly referencing the secret in the dart-define:- APPWRITE_PROJECT_ID: ${{ secrets.APPWRITE_PROJECT_ID }} steps: ... - flutter build appbundle --release \ - --dart-define=APPWRITE_BASE_DOMAIN=${{ secrets.APPWRITE_BASE_DOMAIN }} \ - --dart-define=APPWRITE_PROJECT_ID=${{ secrets.APPWRITE_PROJECT_ID }} + flutter build appbundle --release \ + --dart-define=APPWRITE_BASE_DOMAIN=${{ secrets.APPWRITE_BASE_DOMAIN }} \ + --dart-define=APPWRITE_PROJECT_ID=${{ secrets.APPWRITE_PROJECT_ID }}Alternatively, if the env variable is used elsewhere, keep it. This is a minor polish suggestion.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
.github/workflows/build_and_deploy.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (1)
📓 Common learnings
Learnt from: M4dhav
Repo: AOSSIE-Org/Resonate PR: 510
File: .github/workflows/build_and_deploy.yml:31-36
Timestamp: 2025-08-31T16:18:53.594Z
Learning: For the AOSSIE-Org/Resonate project, build system requirements like Java version setup are considered separate from dependency update PRs and should be handled in dedicated PRs focused on build system improvements.
🔇 Additional comments (6)
.github/workflows/build_and_deploy.yml (6)
3-8: Clarify thedeploy-actionsbranch inclusion.The workflow now triggers on
main,master, anddeploy-actions. Thedeploy-actionsbranch appears to be a test/feature branch but is included in the production workflow triggers. Confirm whether this should be here or if it's residual from development.
14-43: LGTM!The permissions model is correct for GitHub Release creation, and the environment setup (Java 17, Flutter 3.35.2) with proper caching is well-structured. The checkout and setup steps (Java, Android SDK, Flutter) are all necessary and follow best practices.
45-59: LGTM!The secret decoding approach using base64 is standard and correct. The steps properly decode signing keys, Firebase config, and Appwrite credentials into their expected paths for the build.
64-65: Confirm test step expectations.The added
flutter teststep will now execute before the build and can fail the workflow if tests fail. Ensure this aligns with your CI expectations and that test failures should block deployments.
75-76: Note the silent-fail behavior of the AAB verification step.The verification step uses
|| trueto suppress errors if the AAB file doesn't exist. This is intentional for debugging (workflow won't abort if AAB is missing), but means a missing artifact will be silently overlooked until the release deployment fails. Consider whether this trade-off aligns with your error-handling expectations.
78-92: LGTM!The artifact upload and GitHub Release deployment are correctly configured. The
ncipollo/[email protected]step properly sets up the AAB artifact with the correct content type (aab), enables release notes generation, and uses the standard GitHub token for authentication.
|
@M4dhav All the necessary changes are made. I request you to test and merge it. |
|
@uju09 for future reference, user with username CodeRabbit is someone else, and not the CodeRabbit ai Bot. Please tag coderabbitai to request future reviews. Although CodeRabbitAI still detects the command, it is probably annoying for the actual user with the CodeRabbit username. Also, in future, please re-request review via GitHub when changes are done, as I do not open Discord frequently. |
I guess the issue wasn't completely clear, but I meant that for automating deployment to Google Play, we had to shift to using env vars for some of the things, and because of that, the previous build and deploy workflow, which was always suppose to deploy to GitHub Releases, had broken. So because of that, we needed to fix this. |
M4dhav
left a comment
M4dhav
left a comment
There was a problem hiding this comment.
Change all AABs to APKs, apart from that, great work on this PR!
|
@M4dhav I am sorry, I wasn't aware of the coderabbit thing. From now onwards, I will follow the guidelines & will not message on discord. I will make the requested changes. |
Signed-off-by: uju09 <[email protected]>
|
@M4dhav Changes are made. I request to review. |
M4dhav
left a comment
M4dhav
left a comment
There was a problem hiding this comment.
Please verify your PRs before submitting, especially if submitting code written by AI. Also, I would recommend you to test the Workflow on your GitHub by setting up the Action Secrets on your end
|
@M4dhav I am sorry for annoying and disturbing you, but I am a student learning yaml, I just took some suggestions from AI, whole code is not written by AI, I used it for debugging a syntax error and it did some sit work. I apologise for it. I will test and then commit changes. Thank you for co-operating. |
|
I think we should use JAVA 17, as using latest version may cause some compatability issue, but you are demanding to use latest version, so I will commit the changes. |
|
I am not annoyed or disturbed, I apologise if my words came across as that way. I am also a student, and I also use AI to accelerate my developmental workflows, so I understand what you mean. However, I would recommend, even in general, and apart from OSS Contributions, to always review AI generated code with extreme prejudice before committing it to any repo, as AI generated code is most often not ready for production. The workflow I personally used before opening every PR was to use the VSCode Diff Editor to view all my changes across files after staging them and then going to the Git window in VSCode to view just the staged files. This way one can see all their diffs and review them line by line. Anyways, apart from that, the PR is great and pretty much ready to be merged, so great work! Also, Java 21 does not have compatibility issues, as can be verified from it's use in the store_deploy_android workflow, however, Java 17 does cause build errors as can be seen here: As you requested, I tested the workflow on my local before requesting changes, and this screenshot is from a run of GitHub Actions on my fork which failed due to Java 17 incompatibility. |
|
@M4dhav I thought u got annoyed by me. And ur words were right, I haven't minded anything. I am 3rd Sem student from IIIT Dharwad, I am learning on the go. I take every piece of ur word as the advice. So just chill. |
Signed-off-by: uju09 <[email protected]>
|
Failed due to Java incompatibility |
|
I changed the JAVA version |
|
And prev comment too.😂 |
Signed-off-by: uju09 <[email protected]>
|
@M4dhav In the previous commit, by mistakely two lines got removed. I added them in latest commit. |
Signed-off-by: uju09 <[email protected]>
|
@M4dhav I made changes. Any more changes needed? |
|
Please don't mark comments as resolved by yourself |
|
I am sorry for that... I had the habbit of resolving conservation of coderabbit's suggestion |
M4dhav
left a comment
M4dhav
left a comment
There was a problem hiding this comment.
Requesting again, please verify changes before committing
| on: | ||
| push: | ||
| branches: | ||
| - main |
There was a problem hiding this comment.
Resonate has a master branch, not main
| types: [closed] | ||
| branches: | ||
| - master | ||
| workflow_dispatch: |
There was a problem hiding this comment.
Keep workflow_dispatch so that we can trigger the workflow manually
Signed-off-by: uju09 <[email protected]>
Signed-off-by: uju09 <[email protected]>
|
Workflow is working now, thank you for the contribution. Once #585 is fixed, a few additional changes will be required to the workflow, to fetch release tags and notes from the CHANGELOG document, but for now, merging |
|
✅ PR Closed - Thank You, @uju09!
We appreciate your effort and look forward to more contributions from you! 🤝 |
|
@M4dhav Thanks for co-operating with me. |
2 participants
Description
This PR fixes the broken Android CI workflow.
The original file was attempting to build a release app without providing the necessary signing keys or build variables, which caused the build to fail.
This fix replaces the broken workflow with a new, correct workflow (
CI_GITHUB_RELEASE_ANDROID) that:latest_buildtag.Fixes #539
Type of change
Checklist:
Maintainer Checklist
github_workflow