Send errors to stderr when sake is run via sushi

[Mossman1215]

Supporting this dash PR
https://github.com/silverstripeltd/dash/pull/248
given framework hasn't changed since this request
silverstripe/silverstripe-framework#7909
I have found a workaround by loading an INI file called deploy.ini via the environment var PHP_INI_SCAN_DIR

it avoids the flow of deployments failing and the error logs go to syslog rather than stderr

[brettt89]

A nicer way to do this might be to use cli-script.php instead of sake. That way you can control PHP variables directly via the CLI.

E.g. php -d display_errors=stderr framework/cli-script.php dev flush=1

You could potentially repeat / re-use the same logic that sake uses for identifying the location of this cli-script.php file.
https://github.com/silverstripe/silverstripe-framework/blob/a0d00f89510124a7beecee4131c440c0cc8ca8e9/sake#L19

But I also understand this is a bigger change as a whole. (E.g. how does this affect custom stack such as Census who are forging this file etc).

What are your thoughts?

[Mossman1215]

A nicer way to do this might be to use cli-script.php instead of sake. That way you can control PHP variables directly via the CLI.

E.g. php -d display_errors=stderr framework/cli-script.php dev flush=1

You could potentially repeat / re-use the same logic that sake uses for identifying the location of this cli-script.php file.
https://github.com/silverstripe/silverstripe-framework/blob/a0d00f89510124a7beecee4131c440c0cc8ca8e9/sake#L19

But I also understand this is a bigger change as a whole. (E.g. how does this affect custom stack such as Census who are forging this file etc).

What are your thoughts?

As platform we don't control cli-script.php that comes via the codebase.
So this workaround is to fix it in the platform while the OSS peeps work on their complete overhaul of console comands

silverstripe/silverstripe-framework#5542
Jake's already tried to change cli-script in 2018
silverstripe/silverstripe-framework#7909
which was closed.
So although this is a messy hack it's a workaround for our lack of coordination on the OSS side.

[brettt89]

A nicer way to do this might be to use cli-script.php instead of sake. That way you can control PHP variables directly via the CLI.
E.g. php -d display_errors=stderr framework/cli-script.php dev flush=1
You could potentially repeat / re-use the same logic that sake uses for identifying the location of this cli-script.php file.
https://github.com/silverstripe/silverstripe-framework/blob/a0d00f89510124a7beecee4131c440c0cc8ca8e9/sake#L19
But I also understand this is a bigger change as a whole. (E.g. how does this affect custom stack such as Census who are forging this file etc).
What are your thoughts?

As platform we don't control cli-script.php that comes via the codebase.
So this workaround is to fix it in the platform while the OSS peeps work on their complete overhaul of console comands

silverstripe/silverstripe-framework#5542
Jake's already tried to change cli-script in 2018
silverstripe/silverstripe-framework#7909
which was closed.
So although this is a messy hack it's a workaround for our lack of coordination on the OSS side.

Oh, I was meaning change Sushi to use cli-script.php directly instead of sake.

[Mossman1215]

As platform we don't control cli-script.php that comes via the codebase.
So this workaround is to fix it in the platform while the OSS peeps work on their complete overhaul of console comands

silverstripe/silverstripe-framework#5542
Jake's already tried to change cli-script in 2018
silverstripe/silverstripe-framework#7909
which was closed.
So although this is a messy hack it's a workaround for our lack of coordination on the OSS side.

Oh, I was meaning change Sushi to use cli-script.php directly instead of sake.

Right! I don't know what would be missed out if we did invoke cli-script directly and I never considered it.

[brettt89]

Have approved. Feel free to merge when ready, or request another review if changes are needed :).