Closed 0x80 closed 4 months ago
Lately I was thinking the same thing, because every time I update fairebase-tools, this actions breaks and stops continuous deployment.
https://github.com/w9jds/firebase-action/blob/master/entrypoint.sh
I think the point of this actions is to absorb differences in parameter settings, but I would like to hear the Contributer's opinion.
So I have stopped using this actions, while thanking them for their contribution so far. My new code is as follows It works comfortably.
- uses: w9jds/setup-firebase@main
with:
tools-version: 13.4.0
gcp_sa_key: ${{ secrets.GCP_SA_KEY }}
- name: Deploy to Firebase
run: |
firebase deploy --force --only functions:my-function,hosting:my-hosting-site --project my-project-id
rm /opt/gcp_key.json
working-directory: packages/myapp/
Points:
/opt/gcp_key.json
and set the path to the environment variable GOOGLE_APPLICATION_CREDENTIALS
and use it.rm /opt/gcp_key.json
for unexpected security breaches.Incase anyone comes along later, I used the google-github-actions/auth@v2
to login to my Google account before running the npm script.
This is a short version of how it looks in my Github actions:
firebase-functions:
name: Firebase Functions
runs-on: ubuntu-latest
env:
PROJECT_ID: ${{ var.PROJECT_ID }}
- name: Google Auth
uses: google-github-actions/auth@v2
with:
credentials_json: ${{ secrets.GCP_SERVICE_ACCOUNT }}
- name: Firebase Functions
working-directory: ./apps/functions
run: npm run deploy
This is in the package.json script:
"scripts": {
"deploy": "firebase deploy --only functions --project=$PROJECT_ID"
},
Switching to this version also helped me avoid some strange IAM errors that I could not overcome which looked like this:
Unable to set the invoker for the IAM policy on the following functions:
my-function-name(us-central1)
Some common causes of this:
- You may not have the roles/functions.admin IAM role. Note that roles/functions.developer does not allow you to change IAM policies.
- An organization policy that restricts Network Access on your project.
One or more functions were being implicitly made publicly available on function create.
Functions are not implicitly made public on updates. To try to make these functions public on next deploy, configure these functions with invoker set to "public"
Thanks for sharing.
I was working on this a bit recently and learned that using service account credentials is no longer recommended for github actions.
Thanks for sharing.
I was working on this a bit recently and learned that using service account credentials is no longer recommended for github actions.
Yep I agree, but I'm also using Firebase Admin SDK which unfortunately does not support Workload Identity Federation. So I have to resort to service account credentials for now.
The docs for the google-github-actions/auth@v2 action have a warning about it:
Warning: This option is not supported by Firebase Admin SDK. Use Service Account Key JSON authentication instead.
Also FYI if you're using Terraform to stand up Firebase resources you might also get caught up in that issue and you have to use service account credentials. I spent a couple fun days figuring that out. There is a solution hopefully incoming shortly. Here is the long running issue for anyone interested: https://github.com/firebase/firebase-admin-node/issues/1377. There is a solution hopefully incoming shortly.
Thanks that's good to know! I didn't integrate github actions yet.
In the past, I've defined
firebase-tools
as a dev dependency, and installed it in github actions with the other dependencies. Then you can execute any command as usual, or via a package.json script entry like- run: pnpm run deploy:prd
.
I think a main point of this package is so that you don't have to include firebase-tools as a dev dependency. Right now I'm using Bun.sh to deploy my project. The current version of Bun.sh has some issues with the firebase-tools package and breaks deployment. This package lets me get around that.
Yeah, ideally there is no reason to have firebase-tools
as a dependency for a project. On top of that, you also don't want to include credentials for firebase-tools
inside of your repo either. This was created when Actions were in alpha, so it's been around quite a while and gone through many iterations, even transitioned overed to setup-firebase
as the next logical step (since github kind of limits docker actions now, making it harder to make this update properly automatically. It needs a lot of hand holding and custom pipelines).
It's not mandatory to use, but it's pretty common best practice not to include stuff like this inside of your repo. Obviously, you do what is best for your use case. This was created to just allow you to easily configure and setup a firebase deployment, testing, etc. system without having to build everything in your repo.
Our use case for this is convenience and to avoid having a service account key for the admin-sdk service account in our GitHub secrets (we disable service account key creation via org policy anyway).
You can auth with google-github-actions/auth
using workload identity for short lived tokens (set the admin-sdk service account as a workload identity service account for your pool/provider config), and use the credentials from GOOGLE_APPLICATION_CREDENTIALS
passing that to this action like so:
- name: 'Authenticate to Google Cloud'
id: 'auth'
uses: 'google-github-actions/auth@v1'
with:
create_credentials_file: 'true'
project_id: ${{ vars.PROJECT_ID}}
workload_identity_provider: 'projects/${{ vars.PROJECT_NUMBER }}/locations/global/workloadIdentityPools/default-pool/providers/firebase-provider'
service_account: '${{ vars.SERVICE_ACCOUNT }}' # your firebase-admin-sdk service account
- name: firebase-account-key
id: firebase-account-key
shell: bash
run: |
echo GCP_SA_KEY=$(cat $GOOGLE_APPLICATION_CREDENTIALS | base64 -w 0) >> "$GITHUB_OUTPUT"
I am having a hard time seeing any benefits that this action brings.
In the past, I've defined
firebase-tools
as a dev dependency, and installed it in github actions with the other dependencies. Then you can execute any command as usual, or via a package.json script entry like- run: pnpm run deploy:prd
.What does this action allow me to do easily that would be problematic with my current approach?