hmmm imo we should not merge this. If the user wants to know the "short name" of the function he can look at serverless.yml, but I've always used the function name in the info plugin to know the "lambda name" so that I know what to look for in the AWS console, since most users don't necessarily know our default naming convention.

So I see no value in displaying the short name in the CLI, but I see some value for displaying the actual lambda name in the CLI

Just my two cents 😊 🙌

Is it a breaking change?: MAYBE...

Do you think some users might be using the stdout of the CLI in CI or such systems?

The main problem with the current approach is that new users who come to the framework might have problems with that since they do smth. like the following:

serverless create -t aws-nodejs

serverless deploy

Then they see the output of the info and then they want to invoke the function with the name they get from the info output.

@brianneisler stumbled upon this issue. At first, I too thought that it makes sense to display the full AWS name. The problem is that our goal is to keep the user out of the AWS console as much as possible. So why should the user see the name the function is deployed under on AWS.

Another valid argument is that he can see the name in the serverless.yml file. But having such a deployment summary is very convenient.

Maybe @brianneisler can share his view about this here.

Do you think some users might be using the stdout of the CLI in CI or such systems?

We've had the exact same issue when @nikgraf reviewed a PR where the output of the info plugin was refactored and slightly changed. We kept it the way it was. After that @nikgraf started a conversation about what we should declare as a breaking change. Not 100% where we ended here. So that's why i left a MAYBE... there 😄

Just pushed a change so that we get the best of both worlds.

The output now looks something like this and includes the name in the serverless.yml file and the deployed name:

Service Information
service: service
stage: dev
region: us-east-1
api keys:
  None
endpoints:
  GET - https://foo.execute-api.us-east-1.amazonaws.com/dev/goodbye
functions:
  hello: service-dev-hello
  goodbye: service-dev-goodbye

Deal Philipp, you are AWESOME! 😄 🥇

Haven't thought about all those points, thanks for clarifying!

Ok I say let's declare this as a breaking change, so that we do our part and notify the user about it. So that means lets merge this after the 1.7 release, and I'll add a note about it as a breaking change. I think it'll hit very few subset of users, but we care about them too 😊

@eahefnawy Thanks for the feedback!

Deal Philipp, you are AWESOME! 😄 🥇

❤️

Adding this to the next milestone as a breaking change sounds good to me!
The granularity of breaking change introduction might be too detailed here, but who knows 😄

BTW. The only user which comes to my mind who parses CLI output is... Serverless 😆

Remember the regex magic for the API keys integration test?

yikes 😅