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

Conditional resources and modules decompilation #1150

Merged
merged 6 commits into from
Dec 17, 2020

Conversation

shenglol
Copy link
Contributor

@shenglol shenglol commented Dec 15, 2020

  • Implemented decompiling conditionals
  • Added an example

Closes #1151.

Copy link
Member

@majastrz majastrz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a comment.

@codecov-io
Copy link

codecov-io commented Dec 15, 2020

Codecov Report

Merging #1150 (30fc795) into main (4b3e8b1) will increase coverage by 0.14%.
The diff coverage is 100.00%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1150      +/-   ##
==========================================
+ Coverage   94.24%   94.38%   +0.14%     
==========================================
  Files         330      331       +1     
  Lines       16067    16355     +288     
  Branches       14       14              
==========================================
+ Hits        15142    15437     +295     
+ Misses        925      918       -7     
Flag Coverage Δ
dotnet 94.95% <100.00%> (+0.13%) ⬆️
typescript 27.20% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
....Decompiler.IntegrationTests/DecompilationTests.cs 98.63% <ø> (ø)
src/Bicep.Core/Syntax/ModuleDeclarationSyntax.cs 100.00% <100.00%> (ø)
src/Bicep.Decompiler/TemplateConverter.cs 86.15% <100.00%> (-0.07%) ⬇️
src/Bicep.Decompiler/UniqueNamingResolver.cs 81.96% <0.00%> (-8.20%) ⬇️
src/Bicep.Core/Semantics/FunctionOverload.cs 94.23% <0.00%> (-0.94%) ⬇️
...cep.Core/Semantics/Namespaces/AzNamespaceSymbol.cs 100.00% <0.00%> (ø)
...Core/Semantics/Namespaces/SystemNamespaceSymbol.cs 100.00% <0.00%> (ø)
...rc/Bicep.Core/Semantics/FunctionOverloadBuilder.cs 93.18% <0.00%> (ø)
src/Bicep.Core/Syntax/SyntaxRewriteVisitor.cs 73.96% <0.00%> (+7.02%) ⬆️

}
}
var publicIpAddressId = {
id: resourceId(publicIpResourceGroupName, 'Microsoft.Network/publicIPAddresses', publicIpName)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be good to tie this contractually to the value of publicIpNewOrExisting as this template is going to be in a broken state if someone tries to deploy it with new and have specified a different resource group for publicIpResourceGroupName

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I refactored the template so that all resourceIds are tied to createNew....

@@ -0,0 +1,263 @@
param location string {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@alex-frankel mind taking a look at this example file?

default: resourceGroup().name
}

var storageAccountId = createNewStorageAccount ? storageAccount.id : resourceId(storageAccountResourceGroupName, 'Microsoft.Storage/storageAccounts/', storageAccountName)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so this pattern is the weird part right? because in the template today you would use the resourceId() function for both new and existing and because the storageAccountName is the same in both cases it happens to work. With bicep we have arguably made it more complex (though I'd argue more obvious).

Going forward this will be something like:

external resource existingStorage ...

var storageAccountId = createNewStorageAccount ? storageAccount.id :  existingStorageAccount.id

Which seems good to me

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh wait nevermind, I got that wrong. It will be:

resource storageAccount 'Microsoft.Storage/storageAccounts@2017-06-01' = if (createNewStorageAccount) {
  name: storageAccountName
  location: location
  kind: 'Storage'
  sku: {
    name: storageAccountType
  }
} else existing ...

Then you use the same symbolic name regardless if the storage account is being created or not. So I think we are good.

Copy link
Member

@anthony-c-martin anthony-c-martin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@shenglol shenglol merged commit ee219d8 into main Dec 17, 2020
@shenglol shenglol deleted the shenglol/decompiling-conditionals branch December 17, 2020 22:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support decompiling conditional resources and modules
5 participants