PHP Fatal error: Uncaught TypeError: Argument 1 passed to Symfony\Component\Console\Helper\ProgressBar::advance() must be of the type integer, null given
freelock opened this issue · 11 comments
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:
- Downloaded the PHAR for release 2.0.2, made executable, moved into /usr/local/bin
- Set environment variables ACQUIACLI_KEY, ACQUIACLI_SECRET to credentials.
- Attempted to use
acquiacli deploy:prepare
andacquiacli code:switch
under both PHP7.2 and 7.3, and got the same exact error.
Expected behavior
Command to complete successfully.
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.
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.
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).
Thanks for the quick fix!
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?
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.
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.
$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.