Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NEW Refactor CLI interaction with Silverstripe app #11353

Merged
merged 1 commit into from
Sep 26, 2024

Conversation

GuySartorelli
Copy link
Member

@GuySartorelli GuySartorelli commented Aug 27, 2024

  • Turn sake into a symfony/console app
  • Avoid using HTTPRequest for CLI interaction
  • Implement abstracted (named "poly" in these PRs) execution path for CLI and HTTP code paths to land in the same place

The idea is that you can define any combination of these in a module or project:

  • pure symfony/console commands for CLI-only interaction
  • pure controllers for HTTP-only interaction (but still in the dev/* route) e.g. /dev/graphql/ide which simply doesn't work in a CLI context
  • "poly" functionality that can be executed from either a CLI context or a HTTP context - but which doesn't need to duplicate all it's output logic based on Director::is_cli()
    • Most /dev/* especially BuildTask subclasses will use this
    • Can also give explicit HTTP routes via director routing rules and add like normal commands for CLI

New sake uses tasks:mytask format in CLI (this is standard for symfony console apps and means we can take advantage of grouping functionality), but the old dev/tasks/mytask syntax will still work for at least the lifetime of CMS 6 so people don't have to immediately rewrite all their scripts. The dev/ aliases are deprecated to be removed in the future.

Flags can also still be passed as arguments (e.g. --flush can still be passed as flush=1) but this is deprecated.

The HTTP /dev/* routes (e.g. /dev/build) will still work exactly the same way they used to, from a user perspective. The only difference is where the code lives, how it's registered, and how the DevelopmentAdmin class calls it - and the fact that additional help info including available parameters are shown in the list views.
I'm pretty sure this is a low-traffic area in terms of customisation but the upgrade path is very straight forward in any case.

Existing BuildTask implementations which echo out their output directly should still work effectively as-is (i.e. just update the method and property signatures but don't update the method body) if people don't want to update to use the new PolyOutput.
The main thing that will change is that you won't have an HTTPRequest anymore - instead get vars and CLI flags will be given via symfony's InputInterface. Should be a very straight forward upgrade.

I've implemented a navigate command (e.g. sake navigate about-us) in case people have weird edge cases where they do explicitly want to use the old HTTPRequest-over-CLI style. But its use will be discouraged in favour of implementing a PolyCommand.

Issue

Copy link
Member

@emteknetnz emteknetnz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Change Hybrid* to Poly*

Reason being that Hybird means AND whereas Poly is OR - e.g. polymorphic

@GuySartorelli GuySartorelli force-pushed the pulls/6/symfony-sake branch 2 times, most recently from 78b06c0 to c95d6dc Compare September 17, 2024 01:12
@GuySartorelli GuySartorelli marked this pull request as ready for review September 17, 2024 02:27
_config/confirmation-middleware.yml Show resolved Hide resolved
_config/logging.yml Show resolved Hide resolved
client/styles/debug.css Show resolved Hide resolved
src/Cli/LegacyParamArgvInput.php Show resolved Hide resolved
src/Cli/Sake.php Show resolved Hide resolved
src/View/SSViewer_DataPresenter.php Outdated Show resolved Hide resolved
templates/SilverStripe/Dev/DevelopmentAdmin.ss Outdated Show resolved Hide resolved
_config/cli.yml Show resolved Hide resolved
_config/cli.yml Show resolved Hide resolved
src/PolyExecution/PolyOutputLogHandler.php Outdated Show resolved Hide resolved
@GuySartorelli GuySartorelli force-pushed the pulls/6/symfony-sake branch 7 times, most recently from b4c359e to 7cb613d Compare September 18, 2024 22:50
src/Cli/Command/NavigateCommand.php Outdated Show resolved Hide resolved
src/Cli/Command/NavigateCommand.php Outdated Show resolved Hide resolved
src/Control/CLIRequestBuilder.php Outdated Show resolved Hide resolved
tests/php/Cli/Command/NavigateCommandTest.php Outdated Show resolved Hide resolved
src/Cli/LegacyParamArgvInput.php Show resolved Hide resolved
src/PolyExecution/PolyOutput.php Outdated Show resolved Hide resolved
src/PolyExecution/PolyOutput.php Outdated Show resolved Hide resolved
src/Dev/Command/DbCleanup.php Outdated Show resolved Hide resolved
Comment on lines +62 to +69
// These lines commented out from the parent class implementation.
// We don't want this opinionated default colouring - it doesn't appear in the ANSI format so it doesn't belong in the output.
// if ($this->inlineStyles) {
// $html = sprintf('<span style="background-color: %s; color: %s">%s</span>', $this->inlineColors['black'], $this->inlineColors['white'], $html);
// } else {
// $html = sprintf('<span class="ansi_color_bg_black ansi_color_fg_white">%s</span>', $html);
// }
// We do need an opening and closing span though, or the HTML markup is broken
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to keep in I think to understand why this exists

src/PolyExecution/PolyCommand.php Outdated Show resolved Hide resolved
src/Dev/BuildTask.php Outdated Show resolved Hide resolved
src/Dev/Command/ConfigAudit.php Outdated Show resolved Hide resolved
src/Dev/Command/DevCommand.php Outdated Show resolved Hide resolved
src/Dev/Tasks/CleanupTestDatabasesTask.php Outdated Show resolved Hide resolved
@GuySartorelli GuySartorelli force-pushed the pulls/6/symfony-sake branch 6 times, most recently from 4b1e49d to 88a1f03 Compare September 25, 2024 00:25

public function __construct(?array $argv = null, ?InputDefinition $definition = null)
{
Deprecation::withNoReplacement(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should rebase it in then so we don't have things break later

$tokens = ArrayLib::insertBefore($tokens, $convertedFlags, '--', true, true);
}
if ($hadLegacyParams) {
// We only want the warning once regardless of how many params there are.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's an E_USER_DEPRECATED? Which is neither. Since we say 'notice' everywhere we should just refer to it as a notice rather than a warning.

- Turn sake into a symfony/console app
- Avoid using HTTPRequest for CLI interaction
- Implement abstract hybrid execution path
@emteknetnz emteknetnz merged commit e46135b into silverstripe:6 Sep 26, 2024
5 of 12 checks passed
@emteknetnz emteknetnz deleted the pulls/6/symfony-sake branch September 26, 2024 05:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants