Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Http trigger path ignored by deployment #84

Open
rdev opened this issue Aug 31, 2017 · 15 comments
Open

Http trigger path ignored by deployment #84

rdev opened this issue Aug 31, 2017 · 15 comments

Comments

@rdev
Copy link

rdev commented Aug 31, 2017

I have a following function config in serverless.yml

functions:
  create-account:
    handler: createAccount
    events:
      - http: create-account

Yet when the deployment runs, I get:

Deployed functions
create-account
  https://us-central1-gcfteststuff.cloudfunctions.net/createAccount

In Deployment Manager dashboard the httpsTrigger value is set to url: create-account. What might be the issue?

@pmuens pmuens added the bug label Aug 31, 2017
@pmuens
Copy link
Contributor

pmuens commented Aug 31, 2017

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) -->

const path = serviceFunc.handler; // NOTE this might change
which is incorrect in that case...

@rdev
Copy link
Author

rdev commented Aug 31, 2017

But isn't this just the summary that's displayed after the deployment is done?
Actual URL appears to be set up here:

if (eventType === 'http') {
const url = funcObject.events[0].http;
funcTemplate.properties.httpsTrigger = {};
funcTemplate.properties.httpsTrigger.url = url;
}

and it seems like it's working correctly, but path is still not being set by deployment manager

@pmuens
Copy link
Contributor

pmuens commented Sep 1, 2017

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...

@rdev
Copy link
Author

rdev commented Sep 1, 2017

@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:
#78 (comment)
And those kinds of paths don't work for me, it always sets path as the name of handler

@pmuens
Copy link
Contributor

pmuens commented Sep 6, 2017

@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.

@rdev
Copy link
Author

rdev commented Sep 6, 2017

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:
screen shot 2017-09-06 at 4 51 07 pm

As you can see, the trigger is the same as handler name.
But here's the same function the Deployment Manager:

screen shot 2017-09-06 at 4 54 39 pm

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 -_-

@pauldps
Copy link

pauldps commented Dec 12, 2017

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.

@samarara
Copy link

samarara commented Sep 8, 2018

Any updates on this? I'm encountering the same issue.

@jbcpollak
Copy link

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.

@thucnc
Copy link

thucnc commented Nov 21, 2018

Me too, this issue is so annoyed. Please advise/help. :(

@campa
Copy link

campa commented Feb 5, 2019

Same problem here !! any news ? or workaround ?

@mikabytes
Copy link

mikabytes commented Apr 5, 2019

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.

@crlane
Copy link

crlane commented Nov 12, 2019

Annoying workaround:

  1. delete the function in GCP
  2. run serverless remove
  3. change the name of the handler and the function export
  4. serverless deploy

@joshuaquek
Copy link

joshuaquek commented Jan 26, 2020

Managed to find a solution to this, that allows for custom naming:

This Serverless.yml worked for me 👍🏼:

image

Things to take note of:

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)

✅Result:

Deployment Manager web console shows this:

image

Storage web console shows this:

image

Cloudfunction web console shows this:

image

Lastly:

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

@DanielFreitasCastro
Copy link

DanielFreitasCastro commented Oct 7, 2022

Any solution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests