phpro / grumphp

A PHP code-quality tool
MIT License
4.11k stars 429 forks source link

Block vs Count #1058

Closed albertocubeddu closed 1 year ago

albertocubeddu commented 1 year ago
Q A
Version latest
Bug? no
New feature? yes
Question? no
Documentation? no
Related tickets N/A

Having a distributed team working in 3 different timezones and multiple different repositories and framework/PHP versions would be great (from a managerial perspective) to allow them to use grumphp in a Count mode. Therefore each manager can slowly introduce enforcement in the codebase and adapt the agreed steps onto the CI/CD (last blocking gateway before going to production).

Network security tools use "block & count" modalities to allow people to adapt quickly to the changes and make sure they can make changes step-by-step without blocking network requests. It would be amazing to have the same modalities on grumPHP, to alleviate the adoption of a new task.

Defending 100% the value of not committing anything with errors as soon as your toolset is well-defined and configured, I would suggest adding an option in the grumphp that allow for non-blocking commit based on the task executed:

e.g. Tasks: PHPUnit: config_file: ~ testsuite: ~ group: [ ] always_execute: false order: null mode: block phpcs: standard: [ our-custom-standard ] mode: count

As an example: This would allow the smooth adoption of "our-custom-standards", having the ability to have a more collaborative discussion between developers and the Engineering Manager based on their needs and requirements.

The workaround we're using at the moment: "the git commit -n", is hard to communicate with +100 developers; Also, it would skip even the task that is already defined and must be run and fixed before the commit.

Let me know if this feature would be something interesting for the community, and we'll try to write a pull request in the next foreseeable future.

veewee commented 1 year ago

Hello @albertocubeddu

I'm not familiar with blocks and counts. Can you tell me a bit more about this and share with me how you would apply these concepts specifically to grumphp?

albertocubeddu commented 1 year ago

I need to familiarize myself with the codebase of grumphp, but I'll take advantage of this thread to congratulate you on such an amazing product! :) It's made my life easier since I started using it 2 weeks ago! The time saving of using this tool vs myself writing .githooks it's incomparable and much more flexible to maintain!

I can (hopefully) deduce that grumphp is running different task(s). If any of them return a status code of "0/error", the entire process is getting blocked by the .githook that expects a (return 1/success) to allow the developer to continue and be able to commit the code.

The different modalities on count/block would allow the manager to decide what task is blocking and what is just "informative/non-blocking".

Why is this crucial in large businesses? Because teams and enterprises nowadays are more people-oriented, they listen to their employees and their feedback. Enforcing a standard before getting enough input it's a recipe for disaster and a way to have developers use a shortcut (git commit -n) to ignore the process!

Giving them a warm-up period where they can start familiarising themselves with the product (see the errors and provide feedback) allows us to drive the change from the bottom and get great exposure and adoption.

In summary, we are talking about a way to enable behavioural change without the need to force developers (from day 1) to comply 100% with a standard and allow them to choose how to tweak it.

From a technical point of view, I do agree with you that none of the defined tasks should be skipped;

How we work at the moment is:

veewee commented 1 year ago

Hello @albertocubeddu

Thanks for the compliments! I'm glad we were able to make your life easier.

Did you check out: https://github.com/phpro/grumphp/blob/master/doc/tasks.md#metadata

This allows you to mark any task as blocking/non-blocking:

grumphp:
    tasks:
        anytask:
            metadata:
                blocking: true|false

You could e.g. split up into 2 different configurations of the same task. One that runs in blocking mode and one with a slightly looser configuration that runs in an informational non-blocking mode.

Is this what you have in mind?

albertocubeddu commented 1 year ago

This is embarrassing!

I used that page the most, but I always clicked on the hyperlink and completely missed the Metadata section!

Thank you very much this is exactly what we need! 👍

veewee commented 1 year ago

No problem, it happens :)