Kontinuierliche Bereitstellung von GitHub in Azure fehlgeschlagen (ASP.NET 5 & MVC 6)

Question

Ich habe Probleme mit Continuous Deployment von GitHub in Azure. Ich habe eine Shared-Preisstufe, und das Problem verschwindet, wenn ich auf die Basic-Preisstufe aufsteige. Dies ist für eine ASP.NET MVC 6-Anwendung (RC1).

Im Wesentlichen bekomme ich folgende Fehlermeldung: http://pastebin.com/PgARgurg

Das Bit, das sich durch ist:

Restore failed 
There is not enough space on the disk. 

Wenn ich direkt aus Visual Studio Shared Tier veröffentlichen funktioniert es gut. Nur wenn die kontinuierliche Bereitstellung verwendet wird, fällt sie um.

Irgendwelche Ideen?

Answer 1

Gemeinsame Instanzen haben sehr begrenzte Ressourcen, insbesondere in Bezug auf die Festplattengröße. Die fortlaufende Implementierung von GitHub erfordert, dass bei jeder Änderung eine Kopie des Codes auf den Datenträger kopiert wird. Dies wird nicht immer sofort (oder überhaupt) bereinigt. Eine direkte Veröffentlichung von Visual Studio in Azure bereinigt die früheren Bereitstellungspakete automatisch. Der Grund dafür, dass das Upgrade für Ihr Tier das Problem löst, ist der dedizierte und erhöhte verfügbare Speicherplatz. Sie sollten auf Basic upgraden, wenn Sie entscheiden, dass kontinuierliche Integration (und damit Speicherplatz) für Ihre Arbeit wichtig sind.

Answer 2

Grundsätzlich wiederhergestellt Pakete Größe NICHT das gleiche wie veröffentlichte Pakete einer Anwendung.
Sie können verstehen, warum dies der Fall ist, indem Sie die wiederhergestellten Pakete öffnen ... Im folgenden Szenario enthält das veröffentlichte Paket beispielsweise nur den erforderlichen Inhalt zum Ausführen der Anwendung.

Restaurierte JSON.NET Packungsinhalt:

Veröffentlicht JSON.NET Packungsinhalt:

So wahrscheinlich sollten Sie die Anwendung von Ihrer kontinuierlichen Bereitstellung veröffentlichen?

Answer 3

Es gibt noch eine andere Einschränkung. Freigegebene Web Apps-Instanzen haben eine Beschränkung auf Temp Folder size of 300Mb.

Eine asp.net 5 RC1-Anwendung verwendet mehr Temp Folder-Speicher als eine Beta8-App. Es ist jetzt fast unmöglich, eine RC1 durch kontinuierliche Integration in einen kostenlosen App-Service zu implementieren.