When configuring CI for a Firebase project, I often see references to either a FIREBASE_TOKEN generated with firebase login:ci or a service account key that (I think) is generated by default for each project.
For my particular use case, I want to do the following:
run online tests (with Firestore) against my test project when running npm run test during my CI build
deploy that code to a different prod project if tests pass
Which one should I use?
I would recommend you to use the FIREBASE_TOKEN. As usually, tokens are better to use, as you can quickly cancel or renew in any issue that you might have it, as well it's easier to manage them a service account and to insert them in the code.
Besides that, the official Firebase documentation - Use the CLI with CI systems - indicates and teaches how to use it with the token, so it seems that indeed, using the token is the best and easier option for you to implement.
Related
Following the Firebase examples to create and deploy a function, I keep failing at the deploy phase.
The error, with --debug enabled, shows:
<<< [apiv2][body] POST
https://cloudfunctions.googleapis.com/v1/projects/actus-poc2/locations/us-central1/functions
{"error":{"code":403,"message":"Cloud Functions uses Artifact Registry
to store function docker images. Artifact Registry API is not enabled
in your project. To enable the API, visit
https://console.developers.google.com/apis/api/artifactregistry.googleapis.com/overview?project=...
Now I was expecting to be able to stay within the confines of the firebase console but this message seems to imply I need to open the Google Cloud Console to enable additional permissions.
Should the code samples better document this?
Or is this a recent change in firebase functions that breaks many of the existing examples?
I need to open the Google Cloud Console to enable additional permissions.
The reason why you need to use the Google Cloud Console is because Cloud Functions for Firebase relies on some Google Cloud services. See.
Function deployments with Firebase CLI 11.2.0 and higher rely on Cloud Build and Artifact Registry.
is this a recent change in firebase functions that breaks many of the existing examples?
Deployments to older versions also do rely on some Google Cloud services. Deployments to older versions use Cloud Build in the same way, but rely on Container Registry and Cloud Storage for storage instead of Artifact Registry.
Should the code samples better document this?
If you do think an update to said documentation could be helpful, here is more about opening Feature requests.
I'm trying to write tests for my Firebase Cloud Functions, specifically the HTTPS ones. The app uses a permissions system in which each signed-up user of the app has their own entry in Firestore storing the list of permissions they have, indexed by their uid. When these functions are called from the client, the function checks context.auth to determine if the user is authenticated, then uses context.auth.uid to find the entry for the user in Firestore and determine if they have permissions to run this function.
I am now trying to write tests for these functions using the online mode, as recommended in Google's documentation. However, there does not seem to be a way (at least in this mode) to control the context.auth.uid or mock it for the test. As a result, it seems like it might be impossible to tests these functions in this mode.
Is there any way to do this I'm missing, or some workaround?
You may use the signInAnonymously method this can create and use temporary anonymous accounts to authenticate with Firebase anonymously. According to Firebase Test SDK online mode means that other Google SDKs used in your function will work as well. Install both firebase-functions-test and Mocha, a testing framework, by running the following commands in your functions folder:
npm install --save-dev firebase-functions-test
npm install --save-dev mocha
Make sure to follow test setup and used the Authenticate with Firebase Anonymously.
I need to set a secret in my functions config but I want to make sure, that this secret cannot be accessed by anyone, even if the person has access to the firebase project and thus the cli itself.
What I mean by that is, if I set the secret in my cli, I can then retrieve this secret firebase functions:config:get. There are people who might have access to the firebase cli of this project that should not be able to access this secret.
Is there a way to achieve this?
The functions configuration you're referring to is only saved on the local machine. It will not be checked into source control. Other developers who use the CLI in the same project, but on different machines, will not be able to see that configuration.
The configuration will be available in the deployed code, however. If each developer needs a fully isolated configuration at runtime, they should each have their own project to work with.
I have two projects for dev and prod. I want to be able to run a script to copy dev config to prod.
Firebase Remote Config has an API for programatically updating Remote Config. But as far as I can tell, you need to init admin with a project-specific service account. It seems like I would need two admin instances, but I'm not sure that's possible?
I'm wondering if someone has done this before and has an example script. Thanks!
See docs:
https://firebase.google.com/docs/remote-config/automate-rc
There is no Firebase Admin SDK for Flutter, so you'll have to implement this on a different platform that is supported. For a list of these platforms and instructions on setting it up, see the documentation on adding Firebase to a server.
For these platforms that the Firebase Admin SDK targets, you can create multiple instances of the FirebaseApp class, and initialize each of them with different credentials and project configuration. For examples of how to do this, see the documentation on initializing multiple apps.
I'm currently building an open-source microservice that makes use of Firebase Database, Hosting & Functions. The plan is to pack everything in a single binary and distribute this. So users will have a hazzle-free, "bring your own Firebase project"-solution. They'll just have to download the binary and their Firebase secret key and can then create a user and deploy the service via CLI.
The problem is, that firebase-tools require a $FIREBASE_TOKEN when deploying via its API. So users would have to install firebase-tools in order to be able to generate that token and they would also have to store it (or re-generate it frequently).
Since I would like to provide a hazzle-free experience, I'd rather generate that token myself with the help of the secret key.
The question is: is this even possible? And if yes: how??
My workaround for this is to reflect the login- and logout-commands of the Firebase-CLI on my own binary's CLI. So the user won't have to install another tool.
To get the refresh_token I then read the data from the firebase-tools-configstore, that is located in the user folder. This feels a little dirty, like accessing a private API. But I couldn't come up with a better solution. And it works.