afrihost / basecommandbundle Goto Github PK

Currently fails as follows

$ if [ "$TRAVIS_PHP_VERSION" != "hhvm" ]; then phpenv config-rm xdebug.ini; fi;
File xdebug.ini does no exist.
The command "if [ "$TRAVIS_PHP_VERSION" != "hhvm" ]; then phpenv config-rm xdebug.ini; fi;" failed and exited with 1 during .

Presumably due to the TRAVIS_PHP_VERSION not matching the specific version of HHVM added in #26

It doesn't have to be amazing, it can merely be how to install it, and then run the tests to see if it works.

It would be cool to have a function that the BaseCommand will always call via it's destructor - as the first act. This can be used to say "hey, will you please SMS me when you're done?"

We can later on build some strategies around this, so we can call our commands with something like:
--done-sms=0821231234
--done-email=[email protected]
--done-task-complete

Based on the feedback on #11, this issue is to start a discussion on how to handle the initialize method on the BaseCommand, so that a user doesn't have to worry to call the parent method.

I think this would be a bit more difficult to handle than the input definition.
The main difficulties currently is the tight coupling on the container and the RuntimeConfig.

One option is to move the initialisation of the RuntimeConfig into an event listener with a very high priority (so it should also be called first before any other listeners). In that event we can set the container parameters as well as the values from the input, then have a setter on the BaseCommand where the runtime config can be injected. I'm not sure if this is the most optimal solution, but currently I'm unsure of another way to approach this.

Currently the logfile name can either be specified manually or will be generated from the name of the file in which the command is defined.

It would be nice to offer other automatic naming algorithms. This issue is for creating the framework for different naming algorithms to be interchanged. A GoF Strategy Pattern may be a good solution here.

An example of another simple algorithm might be one extends the current one but appends the name of the host on which the log originated.

Tasks:

• Framework for switching out algorithm
• Configuration for user to specify which algortihm they wish to use
• Implement another example algorithm to prove the system
• Integrate with Logfile Extension functonality

The cache of the bundled Symfony Application is not cleared in between executions of the PHPUnit test suite. This sometimes causes false positives on test failures (particularly when modifying code that affects Dependency Injection).

Clearing and warming up the Symfony cache is, however, very slow so we should avoid doing this is a setUp() or setUpBeforeClass(). The best option would be if it could be done once per execution of the phpunit.

A potential solution could be to define our own autoloading file that first calls the composer autoloader and then does the cache clear. A console entrypoint has already been added to help with this

Because sometimes you want a new line in the middle of a log entry

Problem: When a command is being run in the background (such as via cron), there is no indication that the execution we terminated early due to an unhandled exception. Symfony outputs an error to the terminal however, in many cases this output is ignored in favour of log files when executing in such an automated background fashion.

Solution: Add a kernel listener for the console.exception event that attempts to log the exception to a logfile if it was thrown by a command that extends BaseComand (using the command's own logger)

We already have something like this in the internal Afrihost codebase:

 public function onConsoleException(ConsoleExceptionEvent $event)
    {
        // If the command is a subclass of AHCommandBase, try log the exception to the command's log file
        if($event->getCommand() instanceof AHCommandBase){
            try{
                /* @var $command AHCommandBase */
                $command = $event->getCommand();
                $exception = $event->getException();

                $message = 'Uncaught Exception Encountered! Message: '.$exception->getMessage().PHP_EOL.
                    'File: '.$exception->getFile().PHP_EOL.
                    'Line: '.$exception->getLine().PHP_EOL;
                $command->getLogger()->addEmergency($message);
                $command->getLogger()->addInfo('Trace: '.$exception->getTraceAsString());
            } catch(\Exception $e){
                // do nothing if logging throws further exception
            }
        }
    }

This just needs to be incorporated in to the BaseCommandBundle so that:

• The listener is an opt in feature (so that we are not forcing everyone's kernel to be clogged up with our listener)
• The log level of the log entry can be defined in config
• Something is done about making the log entry format more compatible. Not everyone likes to have erroneous newline characters in their log files (this breaks parsing)

The last task is probably a 'nice to have'

Currently if the log level is not specified explicitly for a command using setLogLevel() or the --log-level parameter, the default level is WARNING.

It would be nice for this default to be able to be specified in the applications config.yml so that users can have different default values between development, staging and production environments