PHP Fatal error: Uncaught TypeError: Argument 1 passed to Symfony\Component\Console\Helper\ProgressBar::advance() must be of the type integer, null given

[freelock]

Describe the bug
Getting a PHP Fatal error as soon as a progress bar appears, when attempting to use many cloud operations, using the latest 2.0.2 PHAR.

Full error:

PHP Fatal error:  Uncaught TypeError: Argument 1 passed to Symfony\Component\Console\Helper\ProgressBar::advance() must be of the type integer, null given, called in phar:///usr/local/bin/acquiacli/src/Commands/AcquiaCommand.php on line 184 and defined in phar:///usr/local/bin/acquiacli/vendor/symfony/console/Helper/ProgressBar.php:310
Stack trace:
#0 phar:///usr/local/bin/acquiacli/src/Commands/AcquiaCommand.php(184): Symfony\Component\Console\Helper\ProgressBar->advance(NULL)
#1 phar:///usr/local/bin/acquiacli/src/Commands/AcquiaCommand.php(282): AcquiaCli\Commands\AcquiaCommand->waitForNotification(Object(AcquiaCloudApi\Response\OperationResponse))
#2 phar:///usr/local/bin/acquiacli/src/Commands/AcquiaCommand.php(240): AcquiaCli\Commands\AcquiaCommand->backupDb('d9b9dc88-f2c2-d...', Object(AcquiaCloudApi\Response\EnvironmentResponse), Object(AcquiaCloudApi\Response\DatabaseResponse))
#3 phar:///usr/local/bin/acquiacli/src/Commands/DeployCommand.php(38): AcquiaCli\Commands\AcquiaCommand->backupAndMoveDbs('d9b9dc88-f2c2-d...' in phar:///usr/local/bin/acquiacli/vendor/symfony/console/Helper/ProgressBar.php on line 310

To Reproduce
Steps to reproduce the behavior including calling code:

1. Downloaded the PHAR for release 2.0.2, made executable, moved into /usr/local/bin
2. Set environment variables ACQUIACLI_KEY, ACQUIACLI_SECRET to credentials.
3. Attempted to use acquiacli deploy:prepare and acquiacli code:switch under both PHP7.2 and 7.3, and got the same exact error.

Expected behavior
Command to complete successfully.

Screenshots

Desktop (please complete the following information):

• OS: Tried both under Ubuntu 18.04 and 19.10, with PHP from Ubuntu repositories
• Code version/tag: 2.0.2

Additional context
Trying to set up for a CI/CD system... is there a switch to disable the progress bar? I tried passing -y, -n, --ansi, and even --progress-delay=600s with no difference in the output.

[typhonius]

This looks like the phar isn't pulling in configuration correctly from the default config location as I'm experiencing this too with the phar on test. I think there is an error in acquiacli-robo.php which I'm going to create a PR for now.

We can add in disabling the progress bar as a separate feature request if you'd like. Please feel free to create that ticket and I'll get to it when I have some time. I'm also happy for a PR to be contributed if you have specific ideas around how implementation for that would work.

[typhonius]

I'm deploying 2.0.3 now which should be ready to download with acquiacli self:update as soon as the build has finished (approx 5m).

[freelock]

Thanks for the quick fix!

[danshumaker]

Hi, I'm still getting this error with version 2.0.4. See screenshot:

Technically it's a different setup. I'm using the composer installed setup instead of the phar method. But the error is very similar.

[typhonius]

This was caused last time by config not being passed through correctly. How did you install this one? It looks like it's installed globally with composer.

• Do you have a default.acquiacli.yml in that directory
• Have you run the setup command?
• Do you have a file in $HOME/.acquiacli/acquiacli.yml
• Do you use environment variables for your key and secret?

[danshumaker]

We do have the acquiacli.yml file in the project root and the environment variables for the key/secret appear to be in place. The application:list command works (proving succesful authentication?). But commands like c:s and deploy:prepare get the ProgressBar fatal error.

[typhonius]

What's happening here is that the right config files aren't being found which control things like timezone, task timeout etc. This is failing when the tool waits for a notification (https://github.com/typhonius/acquia_cli/blob/master/src/Commands/AcquiaCommand.php#L168-L184).

The default.robo.yml should have prevented this, but it looks like the installation method (global) hasn't been taken into account. I'm starting to think that we should also seed that information in code, rather than in a file.

[danshumaker]

Ok, based on what you said, I moved the config file from the project directory to the $HOME/.acquiacli directory and the command works. For now I can do that file move via our ci environment (docker build) commands and things should go ok! thank you.

[typhonius]

#56 I've put this in as it might assuage your issues.

[danshumaker]

I'm curious what root is set to here:

acquia_cli/src/Cli/Config.php

Line 17 in 67d1fd0

public function __construct($root)

If it's the pwd then it should have worked as is with line:

acquia_cli/src/Cli/Config.php

Line 25 in 67d1fd0

$projectConfig = $root . '/acquiacli.yml';

. However line 31 is slightly different so perhaps that will work now.

[typhonius]

$root depends on where the library is. If it’s a phar, it’s the phar path, if it’s on it’s own in a git clone, it’s the root of the clone, if it’s required as part of another package, its the root of that package.

I think it was probably a bug to have the default config associated with root as it’s position will never change.