I am try to deploy my function but this keep failing.
Currently The Function is deploy on NodeJS 10. I Reworked the code and deployed with Node Version 12.
I am using CLI of firebase.
The deploy failed and asked to check the log in cloud console and this was the log:
{
"textPayload": "ERROR: build step 2 \"us.gcr.io/fn-img/buildpacks/nodejs10/builder:nodejs10_20210505_10_24_1_RC00\" failed: step exited with non-zero status: 1",
"insertId": "c3362881-be3d-4d52-965d-84793fde26ed-174",
"resource": {
"type": "build",
"labels": {
"project_id": "ecutter",
"build_id": "c3362881-be3d-4d52-965d-84793fde26ed",
"build_trigger_id": ""
}
},
"timestamp": "2021-05-24T19:49:39.640786230Z",
"severity": "INFO",
"labels": {
"build_step": "MAIN"
},
"logName": "projects/ecutter/logs/cloudbuild",
"receiveTimestamp": "2021-05-24T19:49:39.769241759Z"
}
What i tried ?
At first i deployed the function and it failed.
I thought it could be becz of node version so i tried to update the node version of deployed function from cloud console but it failed.
Tried Reinstalling Node Versions npm modules but none helped.
What's going on ?
Related
I am trying to distribute an electron project. So I follow the official guide and use electron-forge. Here is my config.forge:
"config": {
"forge": {
"packagerConfig": {
"asar":true,
"ignore":[
"^/[.].+$",
"^/app/src$",
"^.*/tsconfig([.].*)?[.]json",
"^/angular[.]json",
"^/frontend$",
"^/build$"
]
},
"makers": [
{
"name": "#electron-forge/maker-squirrel",
"config": {
"name": "my-app"
}
},
{
"name": "#electron-forge/maker-zip",
"platforms": [
"darwin"
]
},
{
"name": "#electron-forge/maker-deb",
"config": {}
},
{
"name": "#electron-forge/maker-rpm",
"config": {}
}
]
}
}
It builds fine without asar:true. But if I add asar:true, it throws this error:
An unhandled rejection has occurred inside Forge:
Error: /var/folders/k1/12r0xrxd01n7zgfpqfxppqm80000gn/T/electron-packager/darwin-arm64/my-app-darwin-arm64/Electron.app/Contents/Resources/app/node_modules/#serialport/bindings-cpp/build/node_gyp_bins/python3: file "../../../../../../../../../../../../../Applications/Xcode.app/Contents/Developer/Library/Frameworks/Python3.framework/Versions/3.8/bin/python3.8" links out of the package
Electron Forge was terminated. Location:
{}
This appears to be caused by this node-gyp issue: https://github.com/nodejs/node-gyp/issues/2713
Node-Gyp now creates links to the detect binary versions, apparently to help it consistently use the same versions during builds. These are left after the build finishes, and they point outside the project directory (e.g. to /usr/bin/python). That makes various tools refuse to bundle your node_modules with these links present.
This is really a bug in node-gyp imo, but fixing that may take some time. You could attempt to contribute a fix for that bug in the node-gyp project yourself, or in the meantime you can work around this by deleting all node_gyp_bins folders in your node_modules before building.
I have an ASP.NET 6 application using Dapr. I works in the local development environment, but when I deploy it to Azure Container Apps, it is unable to reach the Dapr sidecar.
The application is defined in Bicep, with the following settings relevant to Dapr:
"dapr": {
"enabled": true,
"appId": "<redaced>",
"appProtocol": "http",
"appPort": 5032
}
The following environment variables are set on the container:
"env": [
{
"name": "DAPR_HTTP_PORT",
"value": "3500"
},
{
"name": "DAPR_GRPC_PORT",
"value": "3500"
}
]
I use the Dapr SDK, and make the following call: _daprClient.GetStateAsync<ICollection<string>>(STORE_NAME, KEY), which results in an exception with this message: ---> Grpc.Core.RpcException: Status(StatusCode="Internal", Detail="Error starting gRPC call. HttpRequestException: Connection refused (127.0.0.1:3500) SocketException: Connection refused", DebugException="System.Net.Http.HttpRequestException: Connection refused (127.0.0.1:3500).
The documentation for Azure Container Apps states that 3500 is the default port for the Dapr sidecar. Any ideas why this does not work?
I have created an Azure Function in Go. The function is working properly in local machine. But, when I deploy it to Azure, I am getting the below exception:
An attempt was made to access a socket in a way forbidden by its access permissions.
Inner exception method is: System.Net.Http.ConnectHelper+<ConnectAsync>d__1.MoveNext
Error log is here: https://github.com/mpurusottamc/azurefunc-go/blob/master/errorlog.json
local.settings.json file has below code:
{
"IsEncrypted": false,
"Values": {
"FUNCTIONS_WORKER_RUNTIME": "node",
"AzureWebJobsStorage": "<proper storage link>"
}
}
host.json file has golang executable reference as the worker.
{
"version": "2.0",
"logging": {
"applicationInsights": {
"samplingSettings": {
"isEnabled": true
}
}
},
"httpWorker": {
"description": {
"defaultExecutablePath": "hello.exe"
}
},
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[1.*, 2.0.0)"
}
}
My code is hosted in github here: https://github.com/mpurusottamc/azurefunc-go
deploy.sh file contains the deployment script.
Followed this reference article: https://itnext.io/write-azure-functions-in-any-language-with-the-http-worker-34d01f522bfd
Am I missing something?
I updated golang version to 1.14 on my machine. And also applied --force in the deployment script and that resolved the issue for me.
go.mod is updated like this:
module hello
go 1.14
deployment script updated to include --force argument
func azure functionapp publish hellogoapp --force
I am trying to get the PM2 logs in my backend server using PM2 API. I tried going through the docs but almost nothing related to logs.
I tried generating a pm2.launchBus but that only gets me current logs and not the old logs.
Usually for checking the pm2 logs:
run pm2 logs (process Id)
run pm2 show (process Id) and it would tell you the log location
May be not using PM2 API but a workable method would be read the logfile using fs and return to your client app
There isn't an API method to get the log data. You can only read it from disk. If you'd like to get more structured information about the log data you can configure the ecosystem (or process) JSON to either:
Add a timestamp
{
"apps" : [
{
"name": "app",
"script": "main.js",
"log_date_format": "YYYY-MM-DD hh:mm:ss"
}
]
}
Which results in:
2021-07-30 06:34:22: Hello World!
Write log entries as JSON
{
"apps" : [
{
"name": "app",
"script": "main.js",
"log_type": "json"
}
]
}
Which will get you:
{
"message": "Hello World!\n",
"timestamp": "2017-02-06T14:51:38.896Z",
"type": "out",
"process_id": 0,
"app_name": "app"
}
See Log Management docs
I am currently having trouble to debug my Azure Functions Core Tools in VS Code.
I am using the npm package azure-functions-core-tools#2.
As i read on many resources func host start / func start should always start the node process in with --inspect=9229. As you can see this is not the case in my setup:
[4/30/19 4:51:25 AM] Starting language worker process:node "/usr/lib/node_modules/azure-functions-core-tools/bin/workers/node/dist/src/nodejsWorker.js" --host 127.0.0.1 --port 50426 --workerId 3e909143-72a3-4779-99c7-376ab3aba92b --requestId 656a9413-e705-4db8-b09f-da44fb1f991d --grpcMaxMessageLength 134217728
[4/30/19 4:51:25 AM] node process with Id=92 started
[4/30/19 4:51:25 AM] Generating 1 job function(s)
[...]
[4/30/19 4:51:25 AM] Job host started
Hosting environment: Production
Also all attempts of changing the hosting environment failed. I tried to add FUNCTIONS_CORETOOLS_ENVIRONMENT to my local configuration, resulting in an error:
An item with the same key has already been added. Key: FUNCTIONS_CORETOOLS_ENVIRONMENT
I tried to add several environment variables in my launch and task settings, using --debug, changing project settings. Nothing works.
I am currently running this on the Windows Subsystem for Linux (WSL) and except this it works really well.
Anyone has a clue on what i am doing wrong here?
I don't think debug is enabled by default. You will have to set the language worker arguments for this to work as documented.
In local.settings.json
To debug locally, add "languageWorkers:node:arguments": "--inspect=5858" under Values in your local.settings.json file and attach a debugger to port 5858.
With func CLI
You could set this by using the --language-worker argument
func host start --language-worker -- --inspect=5858
In VS Code
If you are developing using VS Code and the Azure Functions extension, the --inspect is added automatically as the corresponding environment variable is set in .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "runFunctionsHost",
"type": "shell",
"command": "func host start",
"isBackground": true,
"presentation": {
"reveal": "always"
},
"problemMatcher": "$func-watch",
"options": {
"env": {
"languageWorkers__node__arguments": "--inspect=5858"
}
},
"dependsOn": "installExtensions"
},
{
"label": "installExtensions",
"command": "func extensions install",
"type": "shell",
"presentation": {
"reveal": "always"
}
}
]
}
You could also set this environment variable directly if you'd like instead of adding it in local.settings.json too.