Child pages
  • [console] Use Symfony Console Component for Automation [5.3.0-B1]
Skip to end of metadata
Go to start of metadata

The Symfony's Console Component (see http://symfony.com/doc/current/components/console/introduction.html) is great way of boosting productivity. It allows to easily create commands to perform various common tasks and invoke them from Shell (Bash/Zsh) with an argument auto-complete support and automatic help page generation for command usage out of the box.

What can be automated:

Direct execution of events

Right now events can be executed from command line using "php tools/run_event.php prefix-special:OnEventName secret-per-instance-hash". This can be automated into following command:

in-portal run-event prefix-special:OnEventName

Unit creation

 Unit concept is very powerful, but when it comes to creating new unit there is always place for human error. It turns out that we've created a lot of units over the years and you can automate most of the process to get developer right on track faster. Following command might help:

in-portal unit:create --prefix widget

We can do this to make is super helpful:

  • create stub files for event handler, tag processor, unit config
  • automatically determine used labels and DB table name based on prefix (will also ensure that prefix is named according to coding guidelines)
  • automatically put correct Fields array definition based on database (no need to manually use "System Tools" and copy paste from there)
  • with the help of additional command options fine-tune unit to be generated, e.g.:
    • add change tracking fields, e.g. CreatedOn, UpdatedOn
    • connect to Priority Helper
    • make sub-item of other unit (automatic setup of foreign key and stuff)
    • you name it

Database migration creation

Right now we have central project_upgrades.sql file where all database migrations are being listed. Because all migrations are in single file a unique revision number must be supplied by developer. Although there is validation in place that there are no duplicate revisions from time to time developers manage to create duplicates. This is a problem because such revisions will be silently ignored and only in time developer will be able figure out that in past particular revision wasn't executed.

If we switch to file-per-revision system (see Incorporate "upgrades.sql" into "project_upgrades.sql" [5.2.1-RC1] and [install] Changing way, how upgrade scripts are stored [5.3.0-B1]) then with help of command from below it will be possible to automatically create unique files for each database migration (including PHP support):

in-portal migration:create "#task-number - Task Description"

Possibilities are limit-less.

Related Tasks

INP-1421 - Getting issue details... STATUS

3 Comments

  1. Here is an idea how to make this CLI tool plug-n-play:

    1. each unit can optionally register it's own command classes (via RegisterClasses option in unit config)
    2. all registered command classes will be available in CLI later on

     

  2. Interesting concept for command discovery:

    1. create "IConsoleCommandProvider" (with "getConsoleCommands" method) and "IConsoleCommand" (with no methods) interfaces
    2. create "ConsoleCommand" empty abstract class, that would implement "IConsoleCommand" interface
    3. create "ConsoleCommandProvider" class, that would implement "IConsoleCommandProvider" and in it's "getConsoleCommands" method do:
      1. use "$this->Application->Factory->getSubClasses('IConsoleCommand')" method to get all command classes (from all modules of course)
      2. make an array of these class instances
      3. return that array
    4. the "ConsoleApplication::getDefaultCommands" method (extends Symfony's Console Application) would do:
      1. use "$this->Application->Factory->getSubClasses('IConsoleCommandProvider')" method to get all command provider classes (from all modules of course)
      2. use "getConsoleCommands" on each of them
      3. add every discovered command to the application

    This approach would allow to inject 3rd-party commands into In-Portal through usage of custom command provider class in any of the modules.

  3. Here is a video of CLI tool (the executable is called "in-portal" and is located in root In-Portal folder):

    In the places where text appears out of nowhere I'm actually pressing TAB to use shell (Bash/Zsh) auto-complete functionality. This comes very handy, when you're not sure what possible arguments/options (e.g. scheduled task name) actually are.