Bicep & Pipeline - Deployment using old results/code

Question

I have a rather complex set of Bicep templates including modules ~3 levels deep that I'm running from an Azure DevOps pipeline.&nbsp;The summary of the issue is that the deployment, as seen in Azure Portal, appears to be somehow pulling code/results from a previous deployment.&nbsp;For example, deployment 20220712195754 is run in at 19:57:54 and fails with the following vague error:&nbsp;&nbsp;&nbsp;{
    "code": "DeploymentFailed",
    "message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.",
    "details": [
        {
            "code": "Conflict",
            "message": {
                "status": "Failed",
                "error": {
                    "code": "ResourceDeploymentFailure",
                    "message": "The resource operation completed with terminal provisioning state 'Failed'."
                }
            }
        }
    ]
}&nbsp;&nbsp;&nbsp;Drilling down into the failure in the portal, the failed event (related to a module) has a timestamp of 12/07/2022, 19:29:42 and all of the results (including the failure) are identical to a deployment I ran at that time which I know failed.&nbsp;I've tried deleting all of the deployments from the portal but the exact same thing happens again.&nbsp;Has anyone else seen this behaviour?&nbsp;Is this a documented side-effect of having complex Bicep templates calling modules within modules?

abunnyuk · Accepted Answer

Through trial &amp; error, I've found the problem.&nbsp;I have the following 2 modules which only run when a variable from a loaded JSON file is set to&nbsp;True:&nbsp;module app_mod 'modules/app.bicep' = if (shr_var.env.deployApp == 'True') {
  scope: appGroup_res
  name: 'app_mod'
  params: {
    app_par: shr_var.app
    env_par: shr_var.env
    eventHubAuthId_par: logEndpoints_mod.outputs.eventHubAuthId
    eventHubName_par: logEndpoints_mod.outputs.eventHubName
    location_par: location_par
    resourceTags_par: resourceTags_var
    vaultAdminId_par: adminGroupId_par
  }
}
module gateway_mod 'modules/gateway.bicep' = if (shr_var.env.deployGateway == 'True') {
  scope: gatewayGroup_res
  name: 'gateway_mod'
  dependsOn:[
    app_mod
  ]
  params: {
    env_par: shr_var.env
    eventHubAuthId_par: logEndpoints_mod.outputs.eventHubAuthId
    eventHubName_par: logEndpoints_mod.outputs.eventHubName
    gateway_par: shr_var.gateway
    location_par: location_par
    resourceTags_par: resourceTags_var
  }
}&nbsp;Running the pipeline with no variables successfully skips the modules.&nbsp;I then added this peering module which is conditional in the same way as the above modules but also has parameters that uses outputs from them:&nbsp;module peerGwApp_mod 'modules/modular/vnetPeering.bicep' = if (shr_var.env.deployPeering == 'True') {
  scope: gatewayGroup_res
  name: 'peerGwApp_mod'
  params: {
    localVnetName_par: gateway_mod.outputs.vnetName
    remoteVnetId_par: app_mod.outputs.vnetId
    peeringName_par: 'peer-gw-app'
  }
}&nbsp;Which causes all hell to break loose despite validation having no problems.&nbsp;Regardless of what's in the module (all resource elements have been commented out), apparently conditionally declaring a module which has parameters that use outputs from other conditional modules (that don't run) makes the deployment absolutely foul itself in a spectacular way.&nbsp;At the very least, validation or the deployment itself should return an error for unsupported implicit dependencies rather than the deployment showing previous results.&nbsp;Where would the best place be for me to raise this bug?

Forum Discussion

Bicep & Pipeline - Deployment using old results/code

1 Reply

Resources