[5.28] CollectorIO and skipped actions

[llaville]

I'm late on release the first version of my plugin because I've found a bad behavior with Capt'N 5.28 when using IO\CollectorIO and action skipped.

As it is not blocking, I'll come back later to explain in details what I found !

In summary, Capt'N won't prints messages queued in CollectorIO at end of process, if you manage an action with a condition that tell to skip it into a beforeAction function of a plugin.

Context and behavior found because I wanted my plugin to avoid User to code the Condition step into their captainhook.json

For example :

Rather than writing such configuration (that is valid and acceptable by my plugin)

{
    "config": {
        "allow-failure": false,
        "bootstrap": "examples/vendor-bin-autoloader.php",
        "ansi-colors": true,
        "git-directory": ".git",
        "fail-on-first-error": false,
        "verbosity": "normal",
        "plugins": [
            {
                "plugin": "\\Bartlett\\CaptainHookBinPlugin\\BinPlugin"
            }
        ]
    },
    "pre-commit": {
        "enabled": true,
        "actions": [
            {
                "action": "{$ENV|value-of:VENDOR_BIN_DIR|default:vendor/bin/}phpcs --standard=.github/linters/.phpcs.xml.dist --warning-severity=0 --colors {$STAGED_FILES|of-type:php|separated-by: }",
                "config": {
                    "label": "Checks Coding Standard (with PHP_CodeSniffer)"
                },
                "conditions": [
                    {
                        "exec": "\\Bartlett\\CaptainHookBinPlugin\\Condition\\PackageInstalled",
                        "args": ["squizlabs/php_codesniffer", "^3.3 || ^4.0"]
                    }
                ]
            }
        ]
    }
}

I wanted to just write

{
    "config": {
        "allow-failure": false,
        "bootstrap": "examples/vendor-bin-autoloader.php",
        "ansi-colors": true,
        "git-directory": ".git",
        "fail-on-first-error": false,
        "verbosity": "normal",
        "plugins": [
            {
                "plugin": "\\Bartlett\\CaptainHookBinPlugin\\BinPlugin"
            }
        ]
    },
    "pre-commit": {
        "enabled": true,
        "actions": [
            {
                "action": "{$ENV|value-of:VENDOR_BIN_DIR|default:vendor/bin/}phpcs --standard=.github/linters/.phpcs.xml.dist --warning-severity=0 --colors {$STAGED_FILES|of-type:php|separated-by: }",
                "config": {
                    "label": "Checks Coding Standard (with PHP_CodeSniffer)"
                },
                "options": {
                    "package-require": [
                        "squizlabs/php_codesniffer",
                        "^3.3 || ^4.0"
                    ]
                },
            }
        ]
    }
}

[llaville]

To understand what was printed (by image)

[llaville]

Compare previous run when action was marked as skipped into a beforeAction of a plugin, and the standard way when you code a conditions step, that gave following output (CollectorIO prints messages at end)

[sebastianfeldmann]

I have to investigate this in a bit more detail. Sorry couldn't find the time until now. Will look at it on the weekend.

[llaville]

Now, I've officially make my plugin public, you can see source code at https://github.com/llaville/captainhook-bin-plugin/blob/main/src/BinPlugin.php that show how it is handled !

@sebastianfeldmann FYI : when we code the Condition class but DO NOT prefix it with \\, CaptainHook consider it as a cli type, and not a php type action.
This is because ::class pseudo type does not fully qualified with root base \\ the class name.

 $condition = new Config\Condition('\\' . PackageInstalled::class, $packageRequirement);

[llaville]

Another use case (important for me) was explained at #293 (comment) related to Unit Testing

PS: I dupplicate here my conclusion, because I think it's really important !

For me, you cannot write unit test case with mocking and never invocation rule with usage of ActionNotApplicable exception syntax.

[llaville]

With recent context issue found (see discussion #310), I'd prefer to have a plugin that do what i's expected to do rather than unit tests correctly PASSED.

I'll provide a fix release (my first one ;-) ) for my plugin to solve this situation !