Being able to trigger tests on mob start

[MrGung]

I'd like to run (some) tests after successfull mob start, so that I can validate the current state of the code.

To enter solution-land I'd suggest adding a hook in the vein of MOB_NOTIFY_COMMAND.

To go further (another idea)
If that hook were present, I'd also use it to register the current source-project so that I could automatically call mob next upon closing the dialog I display with MOB_NOTIFY_COMMAND. I wouldn't have to type mob next after closing the dialog.

[simonharrer]

I'd like to run (some) tests after successfull mob start, so that I can validate the current state of the code.

To enter solution-land I'd suggest adding a hook in the vein of MOB_NOTIFY_COMMAND.

Love that idea. A simple command line hook would make a lot of sense. I support this.

To go further (another idea)
If that hook were present, I'd also use it to register the current source-project so that I could automatically call mob next upon closing the dialog I display with MOB_NOTIFY_COMMAND. I wouldn't have to type mob next after closing the dialog.

If you have a hook, you can do anyting you like with that hook. This is not something mob would need to be modified for. Or did I miss something? But don't get me wrong - I like the idea you have.

[gregorriegler]

Good Idea. When you think about the wording, keep in mind that somebody else might want to do a mob next hook next.
The name of the hook should be agnostic to its purpose. MOB_START_HOOK would be a better name I think.

[MrGung]

Right - with hooks one could do anything.
I was thinking about another hook but now I think I'd use notify_command directly (display dialog, call mob next on close). Because - that's a hook already. ;-)

Thanks for picking up the idea!

[simonharrer]

@MrGung would you like to have a go at adding the MOB_START_HOOK option?

[MrGung]

Would be a great way to get into Go, for sure. Alas, it's hard to find the necessary time.

I'll take the issue when I find time and it's still open!

[MrGung]

I've looked into it and started to implement executeStartHook().

Please assign me.

Tests don't work on my machine, though - see issue #271.

[101v]

Hi, we would like to have a pre mob done hook. We would use to run the git pre_commit hook.

[MrGung]

Unfortunately we stopped doing mob-programming at my team. 😢 So I wouldn't be able to verify my changes in real life.

The implementation I started can be found at my fork: https://github.com/MrGung/mob/tree/266-trigger-tests-on-mob-start

I unassigned me. Sorry.

[hollesse]

I was just thinking a bit about this feature request. I think pre and post hooks are a good idea. But I think that would not be enough. I would like to configure these hooks for different project differently. But therefore I would need to specify the hooks in the project specific .mob file. But as it is now we do not allow to set commands within the project specific .mob file because it could be used in a bad manor. I think it is good that we do not allow this, but then there is missing an option to add project specific configuration in your user .mob file. What do you think about that @gregorriegler ?

[gregorriegler]

🤔 I understand the security concern with having a project specific .mob configuration.

Otoh, it's cumbersome to have every user configure it, and then maintain all those configs.

Then again, all the things that have been requested with regards to the hooks can be done outside of mob.sh, too.
So this feature is not super urgent.

If we still wanted to do hooks in mob.sh, I think we need a way to have users approve changes to the projects .mob config

The Idea is that when somebody changes the project config and adds a hook, you will be warned on your next mob command, and you can't do anything unless you approve those changes. Maybe with another command mob approve-config (find a better name). The approval would store a date in your local users .mob config. After the approval you don't get the warning again, because the approval date is after the last change made to the project config. So when somebody changes the project config again, the process starts over.

[hollesse]

The Idea is good, but it would not work with the timestamp, because if you clone a repository the timestamp of the files is the timestamp when this file was create on your computer. This is a pitfall I experienced when I was implementing the open last modified file feature. But we could just use a hash of the config file or a hash of specific configuration like commands. But even then we should think about how we want to mark theses configuration files for different projects in the users config file.

[gregorriegler]

Another way would be a hash code

[hollesse]

As nobody asked for the hooks again, I think we should close that issue. What do you think @gregorriegler @simonharrer ?

[gregorriegler]

I think this gets complicated really quickly. first its just one command, then its a command per event, then its many commands per event, then its about handling interrupts, or some othee unforeseen complication. Maybe I am wrong, but I think the way to go here is to wrap mob.sh, and keep mob.sh simple.

[simonharrer]

Maybe combine it with git hooks?

[frulo]

I have continued with the implementation from @MrGung. Should I create a PR?

[gregorriegler]

yes @frulo , go ahead!