Deploying Laravel 8 in Azure has error "fatal: The remote end hung up unexpectedly error: error in sideband demultiplexer"

Question

I've been trying to follow this tutorial: https://learn.microsoft.com/en-us/azure/app-service/tutorial-php-mysql-app?pivots=platform-linux

But instead of the same repo, I've been using my own with Laravel 8 installed. Everything goes smoothly, until the last part where when I tried to deploy it. I've tried this more than a few times (from start to end), and it still has the same errors. I don't know how to proceed from here.

This is the exact error:

remote: PHP executable: /opt/php/7.2.34/bin/php  
remote: Composer archive: /opt/php-composer/1.9.3/composer.phar  
remote: Running 'composer install --ignore-platform-reqs --no-interaction'...  
remote:   
remote: Loading composer repositories with package information  
remote: Warning from https://repo.packagist.org: You are using an outdated version of Composer. Composer 2 is now available and you should upgrade. See https://getcomposer.org/2  
remote: Updating dependencies (including require-dev)  
remote: ................................................................................  
remote: Package operations: 107 installs, 0 updates, 0 removals  
remote:   - Installing voku/portable-ascii (1.5.6): Downloading (100%)  
remote:   - Installing symfony/polyfill-php80 (v1.22.1): Downloading (100%)  
remote:   - Installing symfony/polyfill-mbstring (v1.22.1): Downloading (100%)  
remote:   - Installing symfony/polyfill-ctype (v1.22.1): Downloading (100%)  
remote:   - Installing phpoption/phpoption (1.7.5): Downloading (100%)    Failed to download phpoption/phpoption from dist: /home/.composer/cache/files/phpoption/phpoption does not exist and could not be created.  
fatal: The remote end hung up unexpectedly  
error: error in sideband demultiplexer  

Please help!

Answer 1

What is the size of your your deployment files? I have seen this error given when customers are trying to complete deployments that are larger than their App Service storage.

A simple way to test this would be to temporarily scale your app to something like a standard or premium tier and then attempt your deployment. (please keep in mind that running a more expensive tier will generate more cost. You should consider scaling back down after attempting your deployment to avoid unexpected costs. See here for App Service cost information.)

Webapp storage is limited as it depends on appservice plan that it belongs to. Besides, storage is shared between all webapps inside same appservice plan.

In order to control .git folder and optimize it as well, you should have on your local repository a ".gitignore" file ( apologies as I didn't explain it so well on my first email), It's usually used to avoid committing transient files from your working directory that aren't useful to other collaborators, such as compilation products, temporary files IDEs create.

Ignored files are usually built artifacts and machine-generated files that can be derived from your repository source or should otherwise not be committed.

Some common examples are:

dependency caches, such as the contents of /node_modules or /packages​

compiled code, such as .o, .pyc, and .class files​

build output directories, such as /bin, /out, or /target​

files generated at runtime, such as .log, .lock, or .tmp​

hidden system files, such as .DS_Store or Thumbs.db​

personal IDE config files, such as .idea/workspace.xml

In this way you'll be able to limit git folder growth on your web app ( or web apps) directory. Please, be aware that it's something very specific to each situation/application, so you need to know exactly which kind of files will be included or ignored.

Besides, you can scale your appservice plan to obtain a bigger storage for all web apps within same plan, but it would be just a temporary solution that can help you while you or your team try to use a .gitignore to take commitments size under control.

Please let us know if this resolves your issue. We look forward to your reply.