[Bug Report]: ACR empty after initial publish

[bartlannoeye]

Describe the bug

Over the past week I did set up 2 bicep module registries with ACR on 2 separate tenants. A few days later I now noticed one is still empty rather than having all modules published. Looking at the details in the pipelines, I can indeed see that no modules are published despite "PublishLatest": true and #2410.

To reproduce

It's been a week since, but as far as I can remember I had following steps:

Repo that got published (first):

• Set up new ACR, Service connection, ...
• Clone CARML repository to a feature branch in new repository
• Register all Azure DevOps pipelines
• Update settings file in feature branch
• Manually test changes on a single pipeline to confirm a green build
• Fast-forward main and push main
• All pipelines triggered and ran successfully

Repo that didn't publish:

• Set up new ACR, Service connection, ...
• Clone repository to main in new repository
• Might have pushed main to AzDo (without any pipelines)
• Register all Azure DevOps pipelines
• Update settings file in main branch locally
• Commit settings file and push main
• All pipelines triggered and ran successfully, however no modules were pushed

Code snippet

No response

Relevant log output

VERBOSE: Invoke Get-ModulesToPublish with
VERBOSE: {
  "PublishLatest": true,
  "TemplateFilePath": "/home/vsts/work/1/s/modules/Microsoft.Web/staticSites/deploy.bicep"
}

VERBOSE: Gathering modified files from the pull request
VERBOSE: Looking for modified files under: [Microsoft.Web/staticSites]
VERBOSE: No template file found in the modified module.
VERBOSE: Modified modules found: [0]
VERBOSE: No modules with changes found to publish.
VERBOSE: Invoke Get-ModulesMissingFromPrivateBicepRegistry with
VERBOSE: {
  "TemplateFilePath": "/home/vsts/work/1/s/modules/Microsoft.Web/staticSites/deploy.bicep",
  "BicepRegistryRgName": "***",
  "PublishLatest": true,
  "BicepRegistryName": "***acr"
}

VERBOSE: No modules missing in the target environment

[vegardhw]

Same experience here but random which module is actually published in ACR. Publishing succeeds according to the GitHub workflows.

[bdanse]

I have the same issue. Running Get-ModulesMissingFromPrivateBicepRegistry locally resolved the missing modules. But running from a Microsoft hosted agent (ubuntu) seems to never find any missing modules. Same script only different platform.

The errorVariable result is different on Windows and Linux.

Windows errorRecord contains a exception.response.

$result.Exception.Response 

{
  "StatusCode": 404,
  "ReasonPhrase": "Not Found",
  "Content": "{\"errors\":[{\"code\":\"NAME_UNKNOWN\",\"message\":\"repository \\\"modules\\\" is not found\"}]}\n"
}

Linux errorRecord contain a raw response and only a Status property.

$result.Exception

Status         : 404
ErrorCode      : 
TargetSite     : 
Message        : Service request failed.
                 Status: 404 (Not Found)
                 
                 Content:
                 {"errors":[{"code":"NAME_UNKNOWN","message":"repository \"modules\" is not found"}]}
                 
                 
                 Headers:
                 Server: openresty
                 Date: Wed, 15 Mar 2023 20:26:41 GMT
                 Connection: keep-alive
                 Access-Control-Expose-Headers: REDACTED
                 Docker-Distribution-Api-Version: REDACTED
                 Strict-Transport-Security: REDACTED
                 X-Content-Type-Options: REDACTED
                 X-Ms-Correlation-Request-Id: REDACTED
                 Content-Type: application/json; charset=utf-8
                 Content-Length: 85 /

This seems to do the trick:

$null = Get-AzContainerRegistryTag -RepositoryName $moduleRegistryIdentifier -RegistryName $BicepRegistryName -ErrorAction 'SilentlyContinue' -ErrorVariable 'result'
if ($result.Exception.Response.StatusCode -eq 'NotFound' -or $result.Exception.status -eq '404' ) {
    $missingTemplatePaths += $templatePath
}

[vegardhw]

@bdanse I can confirm that your fix works. No issues so far. Every module is published as expected.

[AlexanderSehr]

Hello together,
I was unable to reproduce the issue (for example, by using an unknown module name / unknown registry name), but I don't see a reason why not add the suggested solution. Opened the PR #3411 .