Genesis builds

This week sees consolidation of the new Genesis bootstrap library with the introduction of the BuildHandler structure.

Genesis builds are an advanced feature specifically designed for frameworks that require their own build step outside of what a third party automated deployment system provides.

While in a lot of scenarios the whole build process of an app should ideally be handled in the dev environment and pushed to production, there are some cases, especially with legacy applications and frameworks, where that is not so straightforward.

Managing live builds is a complicated problem due to the need to locate the correct codebase as a first step at run time (before loading Composer!), and be able to replace the codebase seamlessly at deploy time.

Genesis employs a flip-flop approach between two build folders with a single target run file to be searched for by the bootstrap. When one folder is active, the other is the target for the next build, the run file is created in the new folder and removed from the old. Genesis looks for both run files at the app's entry point and loads all of the code from whichever folder contains one. If neither exist, the app runs straight from source.

Using the build process with your framework or app requires implementing the DecodeLabs\Genesis\Build\Manifest and returning it from your already running Genesis Hub.

The manifest should provide the location of a temp build folder, the active run container folder, a choice of folder and file names, and most importantly a series of iterators providing lists of files and folders to merge into the build.

Full documentation for builds will be coming shortly in the repository and a deep dive into Genesis will follow soon on this blog. Stay tuned.

Terminus & Systemic direct input pipes

A smaller but important update to Terminus and Systemic sees the handling of input in Terminus sessions improved so that chaining of CLI processes automatically passes input without buffering or echoing.

This is critical when asking for sensitive information such as passwords - without it in place, the password you type is visible as you type and echoed by each process in the chain. Not ideal.

To use this new feature, just pass your Terminus session instead of the Deliverance Broker to your System script launcher:

use DecodeLabs\Terminus as Cli;
use DecodeLabs\Systemic;

Systemic::$process->newLauncher('my-sub-process')
    //->setBroker(Cli::getBroker()) - this can be removed
    ->setSession(Cli::getSession())
    ->launch();

Terminus argument parsing

Another small update to Terminus will make CLI command parsing much less finicky - rather than throwing an exception upon discovering an undefined argument, Terminus will automatically create its own best-guess definition and the argument will be added to the list:

use DecodeLabs\Terminus as Cli;

// > $ php my-process.php --good --bad

Cli::getCommandDefinition()
    ->addArgument('-good|g', 'Good argument');

$args = Cli::prepareArguments();
// ['good' => true, 'bad' => true]

Deliverance Broker inputEnabled

The last thing to report this week is the addition of the inputEnabled flag to Deliverance Brokers - this allows temporary disabling of input reading regardless of all other IO state when needed.

use DecodeLabs\Terminus as Cli;

$broker = Cli::getBroker();
$broker->setInputEnabled(false);

$input = $broker->readLine(); // Always null

$broker->setInputEnabled(true);

$input = $broker->readLine(); // Will wait for input again