Minus in GitHub repository name breaks the deployment wizard

[artem-dudarev]

How to reproduce:

1. Open GitHub repository with a minus in the name: https://github.com/artem-dudarev/test-deploy
2. Click the Deploy to Azure button
3. Click Next button on the SETUP step of the wizard
4. The PREVIEW step shows the following error:

The template deployment 'a74fc7da-76f0-4697-93d1-909913e14327' is not valid according to the validation procedure. The tracking id is '5ba790bf-25de-4b35-b9b9-07bf7f787018'. See inner errors for details. Please see http://aka.ms/arm-deploy for usage details.

If you repeat the same steps with different repository which has identical content but different name then PREVIEW step works fine:
https://github.com/artem-dudarev/testdeploy

The only difference between these repositories is the minus in the name: test-deploy vs testdeploy.

[artem-dudarev]

I've found the reason - storage account name can contain only letters and numbers. No dashes.
Considering this I'd like to change the default value for the siteName parameter so it would contain only letters and numbers. Is it possible?

[snobu]

That's correct, letters and numbers only.
https://github.com/Azure/azure-content/blob/master/articles/storage/storage-create-storage-account.md#create-a-storage-account

We would happily accept a PR.

Maybe the siteName parameter could stay untouched and only trim dashes for storage account names?

[hxlnt]

I ran into this issue recently, and even if hyphens are scrubbed with the replace function, the default deployment will give a "deployment failed" message when deploying into a new resource group. (The deployment actually doesn't fail; but users will get an error message stating that it does.) This is because deploying to a new resource group will default to the repo name with hyphens, and as far as I can tell, there is no way to replace the default name on a newly-created resource group from the azuredeploy.json config.

It would be great to be able to change the default name and location of a newly-created RG to mitigate this issue, especially because users will not necessarily get feedback on why their deployment failed (or seemed to have failed).