Closed arabold closed 7 years ago
I will use normalized alias names internally. The dashes have to be replaced by Dash
(others too) to eliminate disambiguities like my-test
and my--test
which would lead to the same myTest
if using a common camel case transform like _.camelCase()
.
The way Serverless does it in its naming module should be the way to go.
Any update on when this might be added in? Our team would love to tie this into our automated deployment (we tag our assets based on JIRA story key, which contains dashes!). Love this plugin so far.
@mbruning24 Sorry, that there wasn't any progress on that yet. I was quite busy with serverless-webpack
which I ... suddenly ... took over.
Adding this should not be much efforts if it is only done for the rule name, and only if it contains disallowed characters (which is a fixed set) to stay backwards compatible. I think I can have a look this weekend.
Released with 1.5.1
FYI, this issue is mentioned as "Support - + in alias names #68" in the README, but only hyphens work. If I try to use a + or I get
The stack alias name "..." is not valid. A service name should only contain alphanumeric (case sensitive) and hyphens. It should start with an alphabetic character and shouldn't exceed 128 characters.
Any update on the above mentioned query. I get an error if I use "_" The stack alias name "..." is not valid. A service name should only contain alphanumeric (case sensitive) and hyphens. It should start with an alphabetic character and shouldn't exceed 128 characters.
@chosme could you provide serverless.yml
example?
I've tried to deploy a new alias called "my-test" using
sls deploy --alias my-test
. Unfortunately this fails with an exception:The alias stack is still created and not cleaned up properly. I suggest to simply use camel casing when appending the alias name to CloudFormation resources. That would fix this while still allowing non alphanumeric characters in the alias name itself.