search

gnustavo / Git-Hooks

Framework for implementing Git (and Gerrit) hooks
http://search.cpan.org/dist/Git-Hooks/
41 stars 17 forks source link

Building Hook TriggerIronMQ #19

Closed mikkoi closed 6 years ago

mikkoi commented 9 years ago

Hi, Gustavo,

I'm going to start writing a new hook. I have set up a remote repository with working dir which is connected to other functions. I have developed a service which runs an HTTPS port for webhooks. When it receives a POST message, it will pull from our central repository. This POST message will originate from IronMQ (www.iron.io) message queue. Now I need a hook which will send a new message to IronMQ. The POST request cannot come directly from the central repo hooks because it would take too much time and create an interdependency. So we use IronMQ to decouple the two processes (pushing and pulling). Basically, these are the requirements: On branch master, when change-set has a commit with a message starting with text "Admin: ", then send a message with some content to IronMQ message queue called "pull-repo".

My plan is also to isolate all the common functionality to package Git::Hooks::TriggerBase which I will then inherit. I think TriggerIronMQ would be a general hook, nothing specific to our company business. What do you think of my plan? Would you accept this hook as part of Git::Hooks?

I would also like to suggest that we start to isolate the main hook handling process into Git::Hooks::Base. This would make it much easier to build new hooks without duplicating so much code.

gnustavo commented 9 years ago

Hi Mikko.

It seems like an interesting idea. However, I'm thinking lately about leaving in the Git::Hooks distribution just the most general purpose plugins. For instance, I'm going to take out the CheckJira plugin and put it in its own independent distribution. This will keep Git::Hooks lean and devoid of any special dependencies, as CheckJira depends on JIRA::REST, for example. After that I'll try to extract all the funcionality specific to support Gerrit from Git::Hooks and, perhaps, turn it into a derived module called Gerrit::Hooks. That will be more difficult and will force me to think hard about how best to serve the needs of plugin developers and derived modules developers, which I think is more or less what you're hinting at with your Git::Hooks::Base suggestion.

So, I suggest that you already start by giving your new plugin its own distribution, ok?

2015-05-03 3:11 GMT-03:00 Mikko Koivunalho notifications@github.com:

Hi, Gustavo,

I'm going to start writing a new hook. I have set up a remote repository with working dir which is connected to other functions. I have developed a service which runs an HTTPS port for webhooks. When it receives a POST message, it will pull from our central repository. This POST message will originate from IronMQ (www.iron.io) message queue. Now I need a hook which will send a new message to IronMQ. The POST request cannot come directly from the central repo hooks because it would take too much time and create an interdependency. So we use IronMQ to decouple the two processes (pushing and pulling). Basically, these are the requirements: On branch master, when change-set has a commit with a message starting with text "Admin: ", then send a message with some content to IronMQ message queue called "pull-repo".

My plan is also to isolate all the common functionality to package Git::Hooks::TriggerBase which I will then inherit. I think TriggerIronMQ would be a general hook, nothing specific to our company business. What do you think of my plan? Would you accept this hook as part of Git::Hooks?

I would also like to suggest that we start to isolate the main hook handling process into Git::Hooks::Base. This would make it much easier to build new hooks without duplicating so much code.

— Reply to this email directly or view it on GitHub https://github.com/gnustavo/Git-Hooks/issues/19.

Gustavo.

mikkoi commented 9 years ago

Hi, Gustavo, Things are moving ahead then. Great! I will prepare the TriggerBase class. Maybe we can work together on the plugin developers "toolkit"? I'm considering more than simple inheritance. Maybe IoC (inversion of control), such as Bread::Board. If you want to "subcontract" some part of development, ask me. If I have the time, I'll gladly help. What should I call my distribution? Git::Hooks::Trigger?

gnustavo commented 9 years ago

2015-05-03 10:55 GMT-03:00 Mikko Koivunalho notifications@github.com:

Hi, Gustavo, Things are moving ahead then. Great!

Yeah, but in a slow pace, since I can work on it mostly on Weekends and Holidays.

I'm considering more than simple inheritance. Maybe IoC (inversion of control), such as Bread::Board https://metacpan.org/pod/Bread::Board.

Hmm... it's Moose based which means that it would impose a penalty on startup time. I want to keep Git::Hooks lean so that it's useable on high traffic Git servers...

If you want to "subcontract" some part of development, ask me. If I have the time, I'll gladly help.

I'll let you know when I'm about to embark in this journey so that we can toss ideas around.

What should I call my distribution? Git::Hooks::Trigger?

It's your baby. You got the right to call it whatever you want. :-)

Trigger is a very general name. It doesn't tell me anything about which hooks can trigger what? Perhaps a more specific name would be more sellable.

What are you trying to acomplish specificaly? Are you trying to automate the pushing of commits to several non-bare clones? If that's what you're after, have you considered the push to deploy http://blog.tfnico.com/2015/05/a-better-way-to-git-push-to-deploy.html technique introduced in Git 2.3 and complemented in the forthcoming Git 2.4 with the new hook push-to-checkout? The next release of Git::Hooks will support this new hook.

Gustavo.

mikkoi commented 9 years ago

I'm considering more than simple inheritance. Maybe IoC (inversion of control), such as Bread::Board https://metacpan.org/pod/Bread::Board. Hmm... it's Moose based which means that it would impose a penalty

Too heavy then. No problem. IoC is more a set of mind. :-)

What should I call my distribution? Git::Hooks::Trigger? It's your baby. You got the right to call it whatever you want. :-)

Needs to be a generic name if and when I build more trigger hooks besides TriggerIronMQ. :-(

[push to deploy] I've read about it. I noticed you had already added push-to-checkout among the hooks in next branch. But it's not quite what we need.

gnustavo commented 6 years ago

Hi Mikko. I'm closing this since we won't pursue the initial idea of adding a new plugin to the distribution.