Open rdev opened 7 years ago
Thanks for reporting @fivepointseven π
π€ it looks like the handler
is used to display the URL in the info
command (and not the value of the http
event definition) --> https://github.com/serverless/serverless-google-cloudfunctions/blob/09f5e36c3cd46f3f65574fdc214743028b13a29f/info/lib/displayServiceInfo.js#L53 which is incorrect in that case...
But isn't this just the summary that's displayed after the deployment is done? Actual URL appears to be set up here: https://github.com/serverless/serverless-google-cloudfunctions/blob/ccd81a56f8d08b8cb30a46d2e23d96c5218828d6/package/lib/compileFunctions.js#L43-L48 and it seems like it's working correctly, but path is still not being set by deployment manager
Thanks for getting back @fivepointseven π
π€ So according to the serverless.yml
in your issue description your path is create-account
and that's the same path you see in the Deployment Manager dashboard (which is correct in that case).
The URL which is displayed after the deployment was done is wrong and displays createAccount
. So we should fix the info
plugin which outputs service information at the end of each deployment, or am I missing something?
Edit: Or is the url
property set by the Deployment Manager but a path
property is missing? Could you share the full output of the Deployment Manager? Not sure if the path
property was added recently...
@pmuens that is like the next step of my issue π
The problem is, that deployment manager receives correct HTTP trigger value, but when function actually gets created, it has a trigger path of handler name
With the serverless.yml from above I expect it to be
https://us-central1-gcfteststuff.cloudfunctions.net/create-account
But instead the URL is
https://us-central1-gcfteststuff.cloudfunctions.net/createAccount
I saw a conversation in #78, specifically this comment:
https://github.com/serverless/serverless-google-cloudfunctions/issues/78#issuecomment-318345066
And those kinds of paths don't work for me, it always sets path as the name of handler
@fivepointseven thanks for getting back π
Right now Google will create a fully-fledged API for you. So you cannot set the path
or method
(as described in the coversation in #78).
The problem is, that deployment manager receives correct HTTP trigger value, but when function actually gets created, it has a trigger path of handler name
I'm not sure if I follow π
. Could you share your serverless.yml
and the setup of your CloudFunction (e.g. a screenshot) so that we can see how everything is setup at Googles end?
My assumption is that the info
command is just wrong and displays the wrong information about your http
service.
Here's serverless.yml:
service: gcftest
provider:
name: google
runtime: nodejs
project: gcftestproject
credentials: ~/.gcloud/keyfile.json
plugins:
- serverless-google-cloudfunctions
package:
exclude:
- node_modules/**
- .gitignore
- .git/**
functions:
create-account:
handler: createAccount
events:
- http: create-account
This is Cloud Functions:
As you can see, the trigger is the same as handler name. But here's the same function the Deployment Manager:
Where httpTrigger is listed correctly.
So the info
command is correct, because it displays what the endpoint actually becomes.
The problem is that actual endpoint creation ignores httpTrigger
. And this is confusing to me because Google allows to set it manually when creating functions in dashboard, and if using function name as endpoint name is by design in Deployment Manager like you're saying, then why would it be listed in the Deployment Manager API documentation -_-
As it is currently, I can only create Google Functions with names matching their handlers.
Example:
exports.http = (request, response) => {
response.status(200).send('Hello World!')
}
service: my-service
...
functions:
my-service:
handler: http
events:
- http: my-service
The above will create a function named "http" and its URL:
https://us-central1-PROJECT_ID.cloudfunctions.net/http
While I would expect a function called "my-service" to be created with the URL:
https://us-central1-PROJECT_ID.cloudfunctions.net/my-service
I think the plugin needs to address this in another way, as in not relying on httpsTrigger, because it clearly has no effect in the function URL. The function name itself does.
I've been manually creating Google Functions and trying to switch to Serverless for deploys, but this issue is preventing me to.
Any updates on this? I'm encountering the same issue.
I'm having the same problem. In fact, for me I can't seem to rename my function from http
to anything else:
functions:
my-service:
handler: http
events:
- http: my-service
If I change it to handler: my-service
, I get an error message: Name in request must be equal to the name of the function.
Me too, this issue is so annoyed. Please advise/help. :(
Same problem here !! any news ? or workaround ?
Same issue here. Only http
seem to work for name, meaning I can't have more than one cloud function. That makes serverless useless. Does anyone know a workaround?
Seeing how this has been open for nearly two years and no progress, I guess we can't expect a solution anytime soon.
Annoying workaround:
serverless remove
serverless deploy
Managed to find a solution to this, that allows for custom naming:
Naming convention has to be all lowercase WITHOUT SYMBOLS OR UPPERCASE. Else you will get the error of Error -------------------------------------------------- Error: Invalid value for field 'resource.name': 'sls-microserviceApp-dev'. Must be a match of regex '[a-z](?:[-a-z0-9]{0,61}[a-z0-9])?' at Gaxios._request (/home/vsts/work/1/s/node_modules/gaxios/src/gaxios.ts:109:15) at processTicksAndRejections (internal/process/task_queues.js:86:5)
I'm using ExpressJS for my routing within the cloudfunction. If you guys are wondering how, there are a few articles online that can be searched up: https://codeburst.io/express-js-on-cloud-functions-for-firebase-86ed26f9144c
Any solution?
I have a following function config in
serverless.yml
Yet when the deployment runs, I get:
In Deployment Manager dashboard the
httpsTrigger
value is set tourl: create-account
. What might be the issue?