I ended up somehow to have 2 functions with 2 codebases, and I do not know now how to remove one of them.
So, when I use firebase deploy --project myelrondstats I get the bellow error:
Error: More than one codebase claims following functions:
projects/myelrondstats/locations/us-central1/functions/ClearCountField24h: enra,myelrondstats
projects/myelrondstats/locations/us-central1/functions/UpdateCountField24h: enra,myelrondstats
How do I remove myelronstats codebase from this 2 functions, that should be only assigned to the enra codebase ?
Related
I'm trying to setup multiple environments for my Vue / Firebase Project.
I have two Firebase Projects
1.) Dev
2.) Prod
The project utilizes Stripe Extension which pulls the API Key from an auto-generated file called:
firestore-stripe-payments.env
which contains:
STRIPE_API_KEY=projects/${param:PROJECT_NUMBER}/secrets/firestore-stripe-payments-STRIPE_API_KEY-xxxx/versions/latest
Where xxxx is a random 4 character string.
That line pulls the value of the key from Google Secret Manager.
Let's say Dev is 'dddd'
and Prod is: 'pppp'
The issue is that I can only define either:
firestore-stripe-payments-STRIPE_API_KEY-dddd
or
firestore-stripe-payments-STRIPE_API_KEY-pppp
At first I tried to create a new value within Google Secret Manager simply called:
firestore-stripe-payments-STRIPE_API_KEY
The thought was this should be a simple fix, and it would pull the associated API_KEY for the project currently being used.
but this causes the error:
Error: firestore-stripe-payments: Found 'projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY/versions/latest' for secret param STRIPE_API_KEY, but this instance was previously using a different secret projects/fooo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.
Changing secrets is not supported. If you want to change the value of this secret, use a new version of projects/foo/secrets/firestore-stripe-payments-STRIPE_API_KEY-dddd.You can create a new version at https://console.cloud.google.com/security/secret-manager?project=fooo
Also, if there is a better place to ask this question please let me know, couldn't find the 'right' room
For this scenario, could you include a separate env (env.dev) file using the following guidelines
.env # loaded in all cases
.env.local # loaded in all cases, ignored by git
.env.[mode] # only loaded in specified mode
.env.[mode].local
For generating separate keys for each environment, I believe from your example you are using a single Stripe Extension on a single project.
Firebase Extensions can support multiple instances of an Extension per project, this will create a separate "dev" secret for you to use.
Additionally, a separate Firebase project with another "Stripe Extension" installation would be recommended to separate any concerns in development.
Firebase cloud functions database.d.ts has the following comment which throws warnings in my IDE and when I deploy my project:
/** #deprecated Removed in next major release to match Web SDK typings. */
path: string;
In many of my cloud functions, I create dictionaries with the keys being paths to realtime database nodes whenever I want to update entries.
This is the exact behavior I need and works without any issues. However, every time I deploy my cloud functions I'm greeted with over 50 warnings that:
path is deprecated: Removed in next major release to match Web SDK typings.
The terminal call that creates these warnings is:
Running command: npm --prefix "$RESOURCE_DIR" run lint
Without the path variable, I'd have to create a custom function to create a path from the DatabaseReference's key and parent keys. That sounds absurd. Is this possibly a lint issue?
There's nothing to indicate in the documentation that they're removing the path variable, and I hate seeing this warning spammed every time I deploy my functions. Is this a legitimate warning, and if so, is there a replacement way of getting the path from a DatabaseReference built into the sdk?
path property deprecated in version 9+ of the node SDK –
Try do a ref.toString() and remove the base URL
Consider:
var adaRef = firebase.database().ref("users/ada");
adaRef.toString()
Will print the full URL: https://firebaseio.com/users/ada
So to just get the path, you substring it out of there. Two ways of doing that are:
adaRef.toString().substring(firebase.database().ref().toString().length-1)
Or:
adaRef.toString().substring(adaRef.root.toString().length-1)
both will print /users/ada
Looking at this pull request[1] on the Admin SDK open-source repo, it looks like the path property was deprecated to create type compatibility between the JavaScript/web SDK and the Node.js Admin SDK.
The client-side JavaScript SDK for Firebase Realtime Database never had a path property. The way to get the path has always been to call toString() explicitly, or to include the reference in a string concatenation.
I have a single .NET Core .proj file and a single Google Cloud project. The .NET Core project is very simple with a single class implementing IHttpFunction and implementing HandleAsync which is the entrypoint. I have a Cloud Build trigger connected to this project's Git repository which is set to run whenever a commit is pushed into main.
I would like to have more functions-- and hoping to not duplicate common functionality between them -- add those functions to the same project. But when I have multiple classes implementing IHttpFunction, Cloud Build fails.
I think there are at least 2 other ways to do this:
Deploy manually and select a function - but can I do this with Cloud Build triggers too?
Have all functions go through a single "dispatcher" endpoint - which seems messy
What's a good way to do this?
I am using Google Firebase Cloud Functions with TypeScript, and I found out that even though each function is deployed separately, they all share the same bundles and dependencies, even if some functions do not use them nor import them.
In my case, one cloud function uses Redis and others don't. I have 10 functions. All 10 functions actually end up importing redis related code even though they don't import them.
Since all functions share the same entry point, index.js. It currently seems it's impossible to have separate tree-shaken bundles / entry points for each function.
This is very inefficient in terms of bundle size / cold start timing / memory / etc. It also means as I have more and more functions, bundle size will grow for all functions together. It's not scalable.
Is there any way to not share the entry point, index.js, and have completely separate bundles by using bundlers like webpack?
You can create a different local Firebase working area (with firebase init) for each function that should deploy in isolation from the others. You will have to instruct the CLI not to overwrite the other functions on deployment using the --only functions:yourFunctionName to deploy it.
Or, you can deploy function using Cloud tools (gcloud) instead of Firebase tools, but you won't be able to use firebase-functions and its TypeScript bindings.
Or, you can lazily load your modules instead of statically loading them at the global scope of your functions, as described in this video.
I don't recommend using webpack. It's not going to be worth your time to get it configured.
You might try better-firebase-functions, which solves this elegantly by automatically lazy loading only the function that is currently invoked by checking the environment variable FUNCTION_NAME - see https://link.medium.com/4g3CJOLXidb
I am trying to figure out how to set up different firebase environments in a flutter project.
I understand how to do this in firebase, I created two projects, one for production, one for the test. Then, in an iOS or Android project, I could use various methods to switch between these two environments using separate google-services.json or GoogleServices-Info.plist files.
In Flutter I found this description of how to separate environments, but it only explains how to differentiate between environments in the flutter code.
How can I get this environment to change what iOS and Android build at compile time? It would even be sufficient simply to allow a file copy hook at build time.
You can switch accounts using FirebaseApp.configure. You can offer your own solution or secret dev panel to switch between them.
The solutions will build flavours and plist implementations will lock you into builds when you deploy for TestFlight + they are messy.
Here's an example: (You could use Assets as well.)
// Load a named file.
let filePath = Bundle.main.path(forResource: "MyGoogleService", ofType: "plist")
guard let fileopts = FirebaseOptions(contentsOfFile: filePath!)
else { assert(false, "Couldn't load config file") }
FirebaseApp.configure(options: fileopts)
I wrote an article about how to do this for Firebase configuration as well as runtime configuration in dart code using flavors and platform channels.
https://medium.com/#matt.goodson.business/separating-build-environment-configurations-in-flutter-with-firebase-doing-it-the-right-way-c72c3ad3621f
Flutter flavors work pretty seamlessly with Android flavors. For iOS you need to create Xcode schemes for each flavor and link them to build configurations.
For dart configuration, you can use platform channels to get the flavor used during the build at runtime. This lets you configure the app without having multiple main.dart files or passing a target argument.
Salvatore Giordano has written a blog post with a detailed description of how to achieve this:
https://medium.com/#salvatoregiordanoo/flavoring-flutter-392aaa875f36
Flutter accepts a parameter --flavor=<flavor> which allows you to select different build flavors. In Android this works as expected, selecting different build flavors. IOS is a little tricker because a scheme is needed for every flavor, and the build configurations in the form of Release-<flavor> are also needed.
Once these parts are in place, they can be used, to select the firebase configuration as you would in any iOS or Android project.
The challenge is getting Dart code to also be aware of the flavor, and the blog post provides no good solution for this. It suggests the standard method of using different entry points can be used, but the correct entry point must be matched to the correct flavor manually by the person invoking the app.
Specifically to Firebase env config you can use this article and this article from CodeMagic which explains how you can set up plist files with build env variables.
If you need to have a different set of values inside your Dart code, like an option you can use this package. It allows to generate Dart class config file from console command params.
Update 12/05/2020
Since Flutter 1.17 you can actually use compile-time variables with --dart-define argument in flutter run and flutter build commands
Here is an article that describes how to specify and use them.
With the release of Flutter for Web to the stable channel, I put together instructions for targeting multiple firebase projects (e.g. dev, staging, prod) from multiple build platforms (i.e. iOS, Android, and Web).