Problem Space
I recently started working on a Git Repository (not of my own creation) that had a repository name containing spaces.
As a helping hand when a repository is created with spaces in the name, the spaces are replaced with %20 when cloned … Unless otherwise specified, however, this would then need to be specified whenever another user/pipeline clones the repo. See the git command below:
git clone https://.../.../my%20repo myrepo
My best practice answer would be, don’t create repositories with names containing spaces, but this one already did.
So what was the problem?
Lets say I have a repository called ‘demo repo’, that would in tern be cloned into a folder called ‘demo%20repo’. In this repository I have some Bicep templates, of which most importantly I have my main Azure Deploy template that orchestrates the others through modules.
Here is what that template looks like:
/**********************************
Bicep Template: Demo Azure Deploy
***********************************/
targetScope = 'resourceGroup'
// ** Parameters **
// ****************
// ** Variables **
// ***************
module moduleDeployment 'storage-account.bicep' = {
name: 'moduleDeployment'
params: {
}
}
// ** Resources **
// ***************
// ** Outputs **
// *************
When you open this file in VS Code with the Bicep Extension installed v0.13.1, you’ll shortly notice that an error has appeared on the module path:
An error occurred reading file. Could not find a part of the path 'c:\src\demo repo\Bicep-Templates\storage-account.bicep'.
As you’ll find, when the Bicep extension checks your file for validity, it translates the %20 into actual spaces as seen in the error message ’\demo repo\’.
This will also prevent your templates from being built into ARM Templates. (This is not the case for Bicep CLI and Azure CLI)
It is also not possible to update the path on the module to contain the %20 as this is considered special characters and will throw more errors if attempted.
Summary
In my situation, the repository was relatively new in creation and little to no refactoring would be required if the name was to be changed. So we removed the spaces out of the repository name and all is well.
The following GitHub issue has been raised: Error in File Reference in a Git Repository Containing Spaces