I recently (2 days ago) upgraded the node runtime engine on our Cloud Functions instance from Node 10 to 12. (Not sure that is a factor, but it is a recent change.)
Since the upgrade I have been using the Cloud Functions project without trouble. Today is the first time I have done a deploy SINCE the deployment to change the node engine. After I did the deploy, ALL of the Runtime Environment Variables were deleted except one labeled FIREBASE_CONFIG.
As a test, I added another test environment variable via the Cloud Functions console UI. I refreshed the page to ensure the variable was there. Then, I ran another deploy, using this command:
firebase use {project_name} && firebase deploy --only functions:{function_name}
After the deploy completed, I refreshed the environment variables page and found that the test variable I had created was now missing.
I'm quite stumped. Any ideas? Thank you!
It is true that the Firebase CLI manages enviroment configuration and does not allow us to set the ENV variables of the runtime during deployment. This has been explained on other post as well, like this one.
I guess you are aware of the difference between the Cloud Functions Runtime Variables and the Firebase Environment configuration, so I will just leave it here as a friendly reminder.
Regarding the actual issue (New deployments erasing previously set "Cloud Functions Runtime Variables"), I believe this must have been something they fixed already, because I have tested with version 9.10.2 of the firebase CLI, and I could not replicate the issue on my end.
I recommend checking the CLI version that you have (firebase --version) and, if you still experience the same issue, provide us with the steps you took.
Related
I have been hunting down the answer to this particular answer for 2 days with no luck.
I updated the Firebase CLI per their request, and then it was incompatible with my NodeJS, so I had to update that to NodeJS 16. After I did that, I am not able to deploy my functions anymore to Firebase, and just get this non-descript error:
Cloud Runtime Config is currently experiencing issues,
which is preventing your functions from being deployed.
I have tried everything I can think of..
Used NVM to try different versions of Node like 10, 12, 14
Updated the Engine in the Package JSON to all different versions
Deleted all my functions from GCP and tried to just reinstall from scratch.
None of those things have done anything to even change the error message, so I have no idea what is going on or even able to see any logs.
I did try to deploy to our STAGING environment and get a different error
Error: Failed to load environment variables from .env.:
- Error Key GCLOUD_PROJECT is reserved for internal use.
I am not sure what changed with this update, but has anyone else seen/solved this error?
I'm having the same issue, and seems to be related to the project data in gcloud/firebase runtime config data, because I can deploy the same code, in other project.
After downgrading firebase-tools to 11.1.0, the deploy worked as before.
I created and initialized a Firebase the project on my machine and Firebase console. However during the CLI initialization process on my machine I did not tick/include Firebase-Functions feature during the feature selection process.
Halfway through the project I realized there where some features on my website that needed cloud functions and now I'm stuck trying to add firebase functions to the project.
Enabling Firebase functions on Firebase console is easy enough but it's making neccessary changes in the source code to enable it that are frustrating (e.g Creating a 'functions' folder in the code, creating a package.json etc). Is there a command to automatically generate this?
You should just be able to run firebase init in the same project again to add Cloud Functions. It will add extra information to your firebase.json for the new products you choose, but will not overwrite what you've already done for Hosting. If you don't trust that process, simply back up your files, run the comment, and revert the changes if you don't like them.
I am trying to find an easy way to roll back to a/the previous version of my firebase function(google cloud function), in case the new release of this firebase function creates a problem to the deployed system.
The way I deploy the functions is via firebase cli (firebase deploy --only functions) and not gcloud cli.
Is there an easy way to roll back to the previous version of the function?
There is currently no rollback feature. You will have to deploy the function again using the source code that you want to have in its place. To make this easier on themselves, developers typically tag their code in source control after a deploy, so that it's easy to check out a specific version of the code to roll back later.
I'm working with Firebase cloud functions and facing errors while deploying the functions. There are different errors every time. Right now, it's "Server Error: Unexpected Response. Please try again". Whereas, Sometimes it's "Server Error. socket hang up"
I checked firebase-debug.log file, which states that service is not available, whereas, as per Status Dashboard, it's working fine
Another Issue with Naming Convention:
Apart from this, i'm facing issues in deployment when i change the function name from helloWorld to something else. It's quite strange as i've total three functions. Two of them are working fine, whereas, when i change the name of helloWorld to something like generateWeeklyReport, newThreadsReport, weeklyReport it fails every time.
I'm using Spark plan of Firebase and right now the names of functions in my index.js file are: helloWorld, quickChatUserReport, activeThreadsReport. Is there any naming convention, or is there any limitation on the number of functions in this plan? I couldn't find anything in the documentation. Please guide.
Side Note: I read that Kaspersky Endpoint security blocks callbacks resulting in deployment failure. I turned off the protection while deploying function + I'm using node version 9.5.0
The issue in my case was that I updated node version after installing firebase tools. This is the thing which caused the problem and I was not even able to run the functions on my localhost.
I had to uninstall firebase tools completely from my machine, remove the node_modules folder from my project and then reinstall both. It worked.
Commands I used are:
npm uninstall -g firebase-tools
npm install -g firebase-tools
Then I tested my functions as:
firebase deploy --only functions --debug //deployment on cloud
firebase serve --only functions --debug //testing on localhost
Adding the --debug flag to your deploy command can provide some additional details
firebase deploy --debug --only functions
It looks like there have been some intermittent service disruptions with cloud functions over the past week, and I wouldn't be surprised if that is what you are experiencing currently, though the Firebase team isn't reporting any outages currently.
My attempted deploy just now failed with the following error:
[2018-03-08T16:55:56.923Z] Error: Firebase.authWithCustomToken failed: First argument must be a valid credential (a string).
However, when I confirm I'm authenticated via "firebase login" I receive:
Already logged in as xxx#gmail.com
I've had this happen on and off over the past few days and it doesn't seem to be related to anything specific in my code or setup.
UPDATE: My deploys just started working again
I have an Angular4 web app, deployed on Azure. Now I want to deploy this app to other environments on Azure: one for testing, one for acceptance and one for production. Every environment has different API endpoints and may have other variables, like Application Insights. All those environments run Angular in production mode.
The way Angular advises you to do this, is by the Enviroment files (environment.test.ts, enviroment.acc.ts, environment.prod.ts). I could configure all the different API endpoints in those files, and run my build with --prod for production for example.
But that is not the way I want to do this. I want to use the exact same application package deployed to test for my acceptance environment, without rebuilding the project. In Visual Studio Online, this is also really simple to configure.
The point is: how can I make my API endpoints differ per environment in that way?
The way I want to do this, is by the App Settings in Azure. But Angular can't get to those environment variables because it's running on the client side. Node.js is running on serverside and could get those App Settings - but if that's the way I need to do it, how do I make Node.js (used in Angular4 CLI) to send those server variables to the client side? And what about performance impact for this solution?
How did you fix this problem for your Angular4 apps on Azure? Is it just impossible to fix this problem with the Azure App Settings?
For everyone with the same question: I didn't fix this problem the way I described above.
At the end, I did it the way Angular wants you to do it: so rebuild for dev, rebuild for acc and rebuild for prod.
In Visual Studio Online, at build time, it builds and tests our code and it saves the uncompiled/unminified code. At release time, it builds en tests it again and releases it to the right environment with the right environment variables (--prod for example).
I don't think there is another way to fix this.
The solution is pretty old school but it works! Although you can use branching or tag for this purpose instead of cloning the code to the package.
The best solution as you said is Azure app settings will be saved as environment variable so you should implement an API with node.js and share the variables you want.
Of course there is an impact because of additional http call, but it's just one time at application start which is about max 5ms and depends on each program policy whether is impact or not.
Another option could be move the variables to the JSON file in the asset folder, and change it at deploy runtime with release pipeline. that's easier implementation but the disadvantage is you will have to use release variables instead of app settings and if you have config changes you will have to update the variable value first and redeploy it, although that works most of the times but sometimes you want to change just like a connection string and you will have to redeploy.