Closed albertocubeddu closed 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?
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:
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?
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! 👍
No problem, it happens :)
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.