"Parameter x-ms-client-prinzipaldateiname ist null oder leer" beim Bereitstellen einer Funktionsanwendung mit Versionskontrolllink in VSTS

Question

Ich möchte automatisch eine verbrauchsplanbasierte Funktionsanwendung in meinen DEV/TEST/PROD-Instanzen bereitstellen. Dazu habe ich im Portal eine Funktions-App manuell erstellt, das Automatisierungsskript kopiert/eingefügt und in mein ARM-Template-Projekt eingebunden. Zu meinem Quellcode automatisch in die Funktion eingesetzt haben App ich den Link zur Repo-/Filiale in der Vorlage integriert:

 "resources": [ 
      { 
       "apiVersion": "2015-08-01", 
       "name": "web", 
       "type": "sourcecontrols", 
       "dependsOn": [ 
        "[concat('Microsoft.Web/sites/', parameters('name'))]" 
       ], 
       "tags": { 
        "displayName": "fnSourceControl" 
       }, 
       "properties": { 
        "repoUrl": "[parameters('repoUrl')]", 
        "branch": "[parameters('repoBranch')]", 
        "isManualIntegration": false 
       } 
      } 
     ] 

Das funktioniert gut, wenn sie von VS oder von der Kommandozeile bereitstellen. Ressourcengruppe wird mit der Funktions-App erstellt und Code wird darin implementiert: Magic! jedoch, wenn sie von einer VSTS Release Definition bereitstellen, schlägt die Bereitstellung mit:

Resource Microsoft.Web/sites/sourcecontrols 'myFunctionApp/web' failed with message '{ 
    "Code": "BadRequest", 
    "Message": "Parameter x-ms-client-principal-name is null or empty.", 
    "Target": null, 
    "Details": [ 
    { 
     "Message": "Parameter x-ms-client-principal-name is null or empty." 
    }, 
    { 
     "Code": "BadRequest" 
    }, 
    { 
     "ErrorEntity": { 
     "Code": "BadRequest", 
     "Message": "Parameter x-ms-client-principal-name is null or empty.", 
     "ExtendedCode": "51011", 
     "MessageTemplate": "Parameter {0} is null or empty.", 
     "Parameters": [ 
      "x-ms-client-principal-name" 
     ], 
     "InnerErrors": null 
     } 
    } 
    ], 
    "Innererror": null 
} 

Diese Frage zu my other question in Bezug auf die ‚Microsoft.Storage/storageAccounts/providers/locks‘ Verteilungsproblem zusammenhängt. Ich denke, es geht in die gleiche Richtung. Ich wollte nicht eine Frage überladen, die beide Probleme vermischt.

Answer 1

Ich sprach mit unserem Experten, und die Antwort ist, dass VSTS-Setup mit einem Service Principal nicht unterstützt wird. Der Grund dafür ist, dass wir für VSTS die Identität des Anrufers annehmen und die VSTS-API für den Benutzer aufrufen. Damit dies funktioniert, muss der Anrufer ein gültiges VSTS-Konto sein. Wenn Sie einen Service Principal verwenden, haben Sie eine Identität, die kein gültiger VSTS-Account ist.

Beachten Sie, dass dies nichts mit der Tatsache zu tun hat, dass Sie eine Bereitstellung aus einer VSTS-Release-Definition bereitstellen. Dasselbe würde bei der lokalen Bereitstellung mit einer Service Principal-Identität passieren.