Integrate Firebase Hosting for automated deployment (#45)#61
Conversation
- Add firebase.json with SPA rewrites and cache headers for Vite dist/ output - Add .firebaserc with default project configuration - Add GitHub Actions workflow for production deploy on main branch push - Add GitHub Actions workflow for PR preview deployments - Add deploy and deploy:preview npm scripts - Add .firebase/ to .gitignore - Update README with deployment instructions and required secrets Closes #45 Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
Adds an if condition to the deploy steps so CI passes gracefully before FIREBASE_SERVICE_ACCOUNT is added to the repo secrets. Co-Authored-By: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
📝 WalkthroughWalkthroughAdds Firebase Hosting deployment infrastructure to the project: a ChangesFirebase Hosting Deployment Infrastructure
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
hrx01-dev
left a comment
hrx01-dev
left a comment
There was a problem hiding this comment.
ok leaving the changes to coderabbitai
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/firebase-deploy.yml:
- Around line 21-22: The GitHub Actions in the firebase-deploy workflow use
mutable version tags instead of immutable commit SHAs, and the checkout action
does not disable credential persistence. For the actions/checkout action at line
22, replace the mutable tag `v4` with a specific commit SHA and add the
`persist-credentials: false` configuration option to reduce supply chain attack
surface. Apply the same commit SHA pinning pattern to the other actions
referenced on lines 24-26 and line 46 to ensure all actions are pinned to
immutable references.
- Around line 44-51: The `if` condition on the Deploy to Firebase Hosting step
is using `secrets.FIREBASE_SERVICE_ACCOUNT` directly, which is not allowed in
GitHub Actions conditional evaluation. To fix this, map the secret to an
environment variable using `env` before the step, then reference that
environment variable in the `if` condition instead of the secret. This allows
the workflow to properly evaluate the condition at runtime.
In @.github/workflows/firebase-preview.yml:
- Around line 22-23: Replace the mutable action reference `actions/checkout@v4`
with its full commit SHA to ensure supply chain security. Additionally, add the
`persist-credentials: false` parameter to the checkout action to disable default
credential persistence. Apply similar SHA pinning to any other action references
on lines 26 and 47 in the workflow file that currently use mutable version tags
like `@v4` or `@v1`.
- Around line 45-51: The if condition in the "Deploy Preview to Firebase
Hosting" step is directly referencing the secret FIREBASE_SERVICE_ACCOUNT, which
violates GitHub Actions limitations that prevent secrets from being accessed in
conditional expressions. Move the secret reference to an env variable at the job
or step level, then update the if condition to check the environment variable
instead of the secret directly to resolve this issue.
In `@README.md`:
- Around line 76-77: The Preview section in the README states that all pull
requests automatically deploy to preview URLs, but this is misleading since the
workflow only allows PRs from the same repository (excluding fork PRs). Update
the Preview bullet point to explicitly clarify that preview URLs are only
generated for pull requests whose head branch is in the same repository, not for
fork pull requests. This will prevent contributor confusion when fork-based
contributions don't receive preview URLs.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ee3064aa-a306-4cbf-be1d-5908deff7a01
📒 Files selected for processing (7)
.firebaserc.github/workflows/firebase-deploy.yml.github/workflows/firebase-preview.yml.gitignoreREADME.mdfirebase.jsonpackage.json
| - name: Checkout | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "firebase-deploy.yml" -type fRepository: hrx01-dev/Servio
Length of output: 100
🏁 Script executed:
cat -n .github/workflows/firebase-deploy.ymlRepository: hrx01-dev/Servio
Length of output: 1947
🌐 Web query:
actions/checkout@v4 persist-credentials default behavior security
💡 Result:
In actions/checkout@v4, the persist-credentials input defaults to true [1][2]. When set to true (the default), the action configures the local Git repository's configuration files within the runner to include the authentication token or SSH key used for the checkout [3][2]. This enables subsequent steps in the same job to execute authenticated Git commands (such as git push or git fetch) without needing to manually re-authenticate [3][4]. The action is designed to remove these credentials during the post-job cleanup phase [3][2]. From a security perspective, there has been long-standing community discussion regarding this default behavior [5][6]. The primary security concern is that by persisting these credentials, any subsequent step in the workflow—including potentially untrusted third-party actions—gains the ability to access and utilize these credentials for the duration of the job [5][6]. To opt out of this behavior and prevent the credentials from being written to the local Git configuration, you should explicitly set the input to false in your workflow definition [3][2]: - uses: actions/checkout@v4 with: persist-credentials: false It is recommended to use the principle of least privilege by configuring appropriate permissions for your GitHub Actions tokens, regardless of this setting [3][6].
Citations:
- 1: https://github.com/actions/checkout/blob/v4/action.yml
- 2: https://github.com/actions/checkout/blob/v4/README.md
- 3: https://github.com/actions/checkout/?tab=readme-ov-file
- 4: https://github.com/actions/checkout/tree/v4
- 5: [security] Escalate concerning default
persist-credentials=trueplease actions/checkout#2312 - 6: Remove
persist-credentialsor change the default tofalseactions/checkout#485
Pin actions to commit SHAs and disable credential persistence.
Line 22 persists checkout credentials by default (persist-credentials defaults to true), and lines 22, 25, and 46 use mutable action tags. Pin actions to immutable commit SHAs and set persist-credentials: false on the checkout action to reduce supply chain attack surface.
Suggested hardening pattern
- name: Checkout
- uses: actions/checkout@v4
+ uses: actions/checkout@<full-commit-sha>
+ with:
+ persist-credentials: false
- name: Set up Node.js
- uses: actions/setup-node@v4
+ uses: actions/setup-node@<full-commit-sha>
...
- uses: FirebaseExtended/action-hosting-deploy@v0
+ uses: FirebaseExtended/action-hosting-deploy@<full-commit-sha>Also applies to: 24-26, 46-46
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 21-22: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 22-22: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/firebase-deploy.yml around lines 21 - 22, The GitHub
Actions in the firebase-deploy workflow use mutable version tags instead of
immutable commit SHAs, and the checkout action does not disable credential
persistence. For the actions/checkout action at line 22, replace the mutable tag
`v4` with a specific commit SHA and add the `persist-credentials: false`
configuration option to reduce supply chain attack surface. Apply the same
commit SHA pinning pattern to the other actions referenced on lines 24-26 and
line 46 to ensure all actions are pinned to immutable references.
Source: Linters/SAST tools
| - name: Deploy to Firebase Hosting | ||
| if: ${{ secrets.FIREBASE_SERVICE_ACCOUNT != '' }} | ||
| uses: FirebaseExtended/action-hosting-deploy@v0 | ||
| with: | ||
| repoToken: ${{ secrets.GITHUB_TOKEN }} | ||
| firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }} | ||
| channelId: live | ||
| projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions secrets in if condition expression allowed syntax
💡 Result:
You cannot directly reference secrets in GitHub Actions if conditional expressions [1][2][3]. Attempting to use syntax like ${{ secrets.MY_SECRET }} within an if block will not function as expected, as the secrets context is not available for evaluation at that stage of the workflow execution [1][3]. To conditionally run a job or step based on the presence or value of a secret, use the following workaround: 1. Map the secret to an environment variable at the job or step level [1][4]. 2. Use that environment variable to evaluate the condition [4][3]. Example of using a secret to conditionally run a step: jobs: example-job: runs-on: ubuntu-latest steps: - name: Set secret as environment variable env: MY_SECRET_VAR: ${{ secrets.MY_SECRET }} run: | echo "SECRET_EXISTS=${{ env.MY_SECRET_VAR!= '' }}" >>
Citations:
- 1: https://github.com/github/docs/blob/main/content/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets.md
- 2: Secrets cannot be used to condition job runs actions/runner#520
- 3: https://stackoverflow.com/questions/70249519/how-to-check-if-a-secret-variable-is-empty-in-if-conditional-github-actions
- 4: https://envmanager.com/blog/github-actions-secrets
🏁 Script executed:
# Check if the repository has the firebase-deploy.yml file and examine the context
git ls-files | grep -i firebaseRepository: hrx01-dev/Servio
Length of output: 323
🏁 Script executed:
cat -n .github/workflows/firebase-deploy.yml | sed -n '40,55p'Repository: hrx01-dev/Servio
Length of output: 770
Use env for the deploy gate instead of secrets in if expression.
Line 45 uses secrets directly in the if condition, which is not allowed in GitHub Actions. The secrets context is unavailable at the workflow conditional evaluation stage and will cause the workflow to fail validation. Gate on an environment variable instead by mapping the secret to env first.
Suggested fix
- name: Deploy to Firebase Hosting
- if: ${{ secrets.FIREBASE_SERVICE_ACCOUNT != '' }}
+ env:
+ FIREBASE_SERVICE_ACCOUNT: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
+ if: ${{ env.FIREBASE_SERVICE_ACCOUNT != '' }}
uses: FirebaseExtended/action-hosting-deploy@v0
with:
repoToken: ${{ secrets.GITHUB_TOKEN }}
- firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
+ firebaseServiceAccount: ${{ env.FIREBASE_SERVICE_ACCOUNT }}
channelId: live
projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Deploy to Firebase Hosting | |
| if: ${{ secrets.FIREBASE_SERVICE_ACCOUNT != '' }} | |
| uses: FirebaseExtended/action-hosting-deploy@v0 | |
| with: | |
| repoToken: ${{ secrets.GITHUB_TOKEN }} | |
| firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }} | |
| channelId: live | |
| projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }} | |
| - name: Deploy to Firebase Hosting | |
| env: | |
| FIREBASE_SERVICE_ACCOUNT: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }} | |
| if: ${{ env.FIREBASE_SERVICE_ACCOUNT != '' }} | |
| uses: FirebaseExtended/action-hosting-deploy@v0 | |
| with: | |
| repoToken: ${{ secrets.GITHUB_TOKEN }} | |
| firebaseServiceAccount: ${{ env.FIREBASE_SERVICE_ACCOUNT }} | |
| channelId: live | |
| projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }} |
🧰 Tools
🪛 actionlint (1.7.12)
[error] 45-45: context "secrets" is not allowed here. available contexts are "env", "github", "inputs", "job", "matrix", "needs", "runner", "steps", "strategy", "vars". see https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability for more details
(expression)
🪛 zizmor (1.25.2)
[error] 46-46: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/firebase-deploy.yml around lines 44 - 51, The `if`
condition on the Deploy to Firebase Hosting step is using
`secrets.FIREBASE_SERVICE_ACCOUNT` directly, which is not allowed in GitHub
Actions conditional evaluation. To fix this, map the secret to an environment
variable using `env` before the step, then reference that environment variable
in the `if` condition instead of the secret. This allows the workflow to
properly evaluate the condition at runtime.
Source: Linters/SAST tools
| - name: Checkout | ||
| uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n .github/workflows/firebase-preview.yml | head -50Repository: hrx01-dev/Servio
Length of output: 1961
Pin action SHAs and disable credential persistence for checkout.
Line 23 uses default credential persistence, and lines 23, 26, and 47 use mutable action refs. Pin to full commit SHAs and set persist-credentials: false on the checkout action.
Suggested hardening pattern
- name: Checkout
- uses: actions/checkout@v4
+ uses: actions/checkout@<full-commit-sha>
+ with:
+ persist-credentials: false
- name: Set up Node.js
- uses: actions/setup-node@v4
+ uses: actions/setup-node@<full-commit-sha>
- name: Deploy Preview to Firebase Hosting
- uses: FirebaseExtended/action-hosting-deploy@v0
+ uses: FirebaseExtended/action-hosting-deploy@<full-commit-sha>🧰 Tools
🪛 zizmor (1.25.2)
[warning] 22-23: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
[error] 23-23: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/firebase-preview.yml around lines 22 - 23, Replace the
mutable action reference `actions/checkout@v4` with its full commit SHA to
ensure supply chain security. Additionally, add the `persist-credentials: false`
parameter to the checkout action to disable default credential persistence.
Apply similar SHA pinning to any other action references on lines 26 and 47 in
the workflow file that currently use mutable version tags like `@v4` or `@v1`.
Source: Linters/SAST tools
| - name: Deploy Preview to Firebase Hosting | ||
| if: ${{ secrets.FIREBASE_SERVICE_ACCOUNT != '' }} | ||
| uses: FirebaseExtended/action-hosting-deploy@v0 | ||
| with: | ||
| repoToken: ${{ secrets.GITHUB_TOKEN }} | ||
| firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }} | ||
| projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }} |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
GitHub Actions secrets in if condition expression context
💡 Result:
In GitHub Actions, you cannot directly reference secrets in if conditional expressions (e.g., if: ${{ secrets.MY_SECRET == 'value' }} will not work) [1][2][3]. This is a documented limitation [1][3]. To conditionally run a job or step based on the value or presence of a secret, use one of the following workarounds: 1. Use environment variables: Define an environment variable at the job or step level using the secret, then reference that environment variable in your if conditional [1][2][4]. Since an unset secret resolves to an empty string, you can check if it is defined by checking if it is not empty [1][3][4]. jobs: example-job: runs-on: ubuntu-latest steps: - name: Run if secret is set env: MY_SECRET_VAL: ${{ secrets.MY_SECRET }} if: ${{ env.MY_SECRET_VAL!= '' }} run: echo "Secret is present" 2. Use github.secret_source: If you need to determine generally if secrets are available (for example, to prevent failures when running workflows from forks), you can use the github.secret_source context in your if condition [5][6]. This property will be 'Actions' if secrets are accessible and 'None' if they are not [6]. jobs: job1: runs-on: ubuntu-latest if: ${{ github.secret_source == 'Actions' }} steps: - run: echo "Secrets are available" 3. Use a separate job for validation: If you need to perform complex logic based on multiple secrets, you can create a dedicated "check" job that evaluates the secrets and sets an output [6]. Subsequent jobs can then use the needs context to conditionally run based on that output [6].
Citations:
- 1: https://docs.github.com/actions/security-guides/using-secrets-in-github-actions
- 2: https://stackoverflow.com/questions/72925899/github-actions-detect-if-secret-exists
- 3: https://github.com/github/docs/blob/main/content/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets.md
- 4: https://envmanager.com/blog/github-actions-secrets
- 5: Secrets cannot be used to condition job runs actions/runner#520
- 6: https://stackoverflow.com/questions/70249519/how-to-check-if-a-secret-variable-is-empty-in-if-conditional-github-actions
🌐 Web query:
GitHub Actions expression context rules secrets available
💡 Result:
In GitHub Actions, the secrets context is used to access repository, organization, or environment secrets within a workflow run [1][2]. Key rules regarding its availability and usage in expressions include: 1. Restriction in Conditionals: You cannot directly reference secrets in if: conditionals [3][4]. If a secret is used directly in an if: expression, the condition will not function as intended because the secret's value is not exposed in that context [3]. The standard workaround is to map the secret to a job-level or step-level environment variable and then reference that environment variable within the if: conditional [3][4]. 2. Availability: The secrets context is generally available within a job, but it is not available for composite actions for security reasons [1][5]. To provide a secret to a composite action, you must pass it explicitly as an input [1][2]. 3. Empty Values: If a referenced secret has not been set, the expression will return an empty string [3]. 4. Best Practices for Expressions: While you can use ${{ secrets.SECRET_NAME }} within expressions (such as when setting environment variables or action inputs), avoid interpolating them directly into shell commands in run: blocks [3][4]. Direct interpolation can lead to secrets appearing in process lists, shell history, or logs [4]. Instead, map the secret to an environment variable and access the environment variable within your script [4]. 5. Automatic Secrets: GITHUB_TOKEN is a built-in secret automatically included in the secrets context for every workflow run [1][6]. For detailed usage, you can map secrets to environment variables as follows: env: MY_SECRET_VAR: ${{ secrets.MY_SECRET }} run:./my-script.sh # access via $MY_SECRET_VAR in the script [4]
Citations:
- 1: https://github.com/github/docs/blob/main/content/actions/reference/workflows-and-actions/contexts.md
- 2: https://docs.github.com/en/actions/concepts/security/secrets
- 3: https://github.com/github/docs/blob/main/content/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets.md
- 4: https://envmanager.com/blog/github-actions-secrets
- 5: https://docs.github.com/enterprise-server@3.0/actions/learn-github-actions/contexts
- 6: https://docs.github.com/en/enterprise-server@3.2/actions/learn-github-actions/contexts
Replace secrets usage in the if expression.
The if condition on line 46 cannot directly reference secrets; this is a documented GitHub Actions limitation. Move the secret to an env variable and check the environment variable in the condition instead.
Suggested fix
- name: Deploy Preview to Firebase Hosting
- if: ${{ secrets.FIREBASE_SERVICE_ACCOUNT != '' }}
+ env:
+ FIREBASE_SERVICE_ACCOUNT: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
+ if: ${{ env.FIREBASE_SERVICE_ACCOUNT != '' }}
uses: FirebaseExtended/action-hosting-deploy@v0
with:
repoToken: ${{ secrets.GITHUB_TOKEN }}
- firebaseServiceAccount: ${{ secrets.FIREBASE_SERVICE_ACCOUNT }}
+ firebaseServiceAccount: ${{ env.FIREBASE_SERVICE_ACCOUNT }}
projectId: ${{ secrets.VITE_FIREBASE_PROJECT_ID }}🧰 Tools
🪛 actionlint (1.7.12)
[error] 46-46: context "secrets" is not allowed here. available contexts are "env", "github", "inputs", "job", "matrix", "needs", "runner", "steps", "strategy", "vars". see https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability for more details
(expression)
🪛 zizmor (1.25.2)
[error] 47-47: unpinned action reference (unpinned-uses): action is not pinned to a hash (required by blanket policy)
(unpinned-uses)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/firebase-preview.yml around lines 45 - 51, The if
condition in the "Deploy Preview to Firebase Hosting" step is directly
referencing the secret FIREBASE_SERVICE_ACCOUNT, which violates GitHub Actions
limitations that prevent secrets from being accessed in conditional expressions.
Move the secret reference to an env variable at the job or step level, then
update the if condition to check the environment variable instead of the secret
directly to resolve this issue.
Source: Linters/SAST tools
| - **Production:** Merges to `main` trigger a build and deploy to the live Firebase Hosting channel. | ||
| - **Preview:** Pull requests automatically deploy to a temporary preview URL (posted as a PR comment). |
There was a problem hiding this comment.
Clarify that preview deploys are limited to same-repository PRs.
Line 77 currently reads as all pull requests get preview URLs, but the workflow condition only allows PRs whose head branch is in this repository. A short note here will avoid contributor confusion.
Suggested wording update
-- **Preview:** Pull requests automatically deploy to a temporary preview URL (posted as a PR comment).
+- **Preview:** Pull requests from branches in this repository automatically deploy to a temporary preview URL (posted as a PR comment).📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - **Production:** Merges to `main` trigger a build and deploy to the live Firebase Hosting channel. | |
| - **Preview:** Pull requests automatically deploy to a temporary preview URL (posted as a PR comment). | |
| - **Production:** Merges to `main` trigger a build and deploy to the live Firebase Hosting channel. | |
| - **Preview:** Pull requests from branches in this repository automatically deploy to a temporary preview URL (posted as a PR comment). |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` around lines 76 - 77, The Preview section in the README states
that all pull requests automatically deploy to preview URLs, but this is
misleading since the workflow only allows PRs from the same repository
(excluding fork PRs). Update the Preview bullet point to explicitly clarify that
preview URLs are only generated for pull requests whose head branch is in the
same repository, not for fork pull requests. This will prevent contributor
confusion when fork-based contributions don't receive preview URLs.
1 participant
Summary
Adds Firebase Hosting configuration and CI/CD workflows so the app can be deployed to Firebase automatically.
New files:
firebase.json— serves Vite'sdist/directory, SPA rewrite (** → /index.html), and long-lived cache headers on/assets/**and*.js|css.firebaserc— default project alias (placeholderservio-app, update to your actual project ID).github/workflows/firebase-deploy.yml— builds and deploys to the live channel on every push tomain, usingFirebaseExtended/action-hosting-deploy@v0. Deploy step is skipped ifFIREBASE_SERVICE_ACCOUNTsecret is not yet configured..github/workflows/firebase-preview.yml— builds and deploys a preview channel on every PR (URL posted as a PR comment), scoped to same-repo PRs only. Deploy step is skipped if secret is missing.Modified files:
package.json— addeddeployanddeploy:previewscripts for manual deployment via Firebase CLI.gitignore— added.firebase/cache directoryREADME.md— added full deployment section: prerequisites, env vars, manual deploy, CI/CD setup, and required GitHub secrets tableRequired setup after merge:
FIREBASE_SERVICE_ACCOUNTandVITE_FIREBASE_*secrets in GitHub repo settings (Settings > Secrets and variables > Actions).firebasercto match your actual Firebase projectCloses #45
Link to Devin session: https://app.devin.ai/sessions/ee17ee110bd04a2296d7047fe7c01b0d
Requested by: @hrx01-dev
Summary by CodeRabbit
Release Notes
Chores
Documentation