Decouple from githooks?

[naholyr]

Decouple from githooks?

[naholyr]

If you can extract the range of commits you want to work on, you can manually call ght _hook -R range -r remote.

But I guess this is not exactly what you want ;)

What would serve you best? I could add some API in front of internals, something like that?

var ght = require("github-todos").hook;

ght.diff({
  "range": "1234567..1234568",
  "remote": "origin"
})
.then(ght.extractTodos) // → [Todo]
.then(ght.hook) // → [[Todo], [Result]]

But a few questions arise:

• What about user interaction? Same as _hook or you want to intercept it to be able to answer by yourself (not so easy but doable)?
• What about configuration (.github-todos and .github-todos-ignore)? Need to override it or just using the files is OK?

[ianwremmel]

Sorry for the delay, holidays and whatnot.

Calling it from bash probably isn't ideal because I'd have to install it globally on that machine.

Basically, the flow I have to work with is as follows:

1. Push changeset to CI
2. CI runs tests
3. If tests pass, CI pushes changeset to master

Ideally, it would run between steps 2 and 3 (if the tests pass).

For this use case, user interaction doesn't matter.

I think that API reasonable (other than, perhaps, range could be an object that with start and end properties). The config files also seem reasonable for now, but I could see how it might be desirable to configure them programmatically at some point.

The more I think about it, I might be able to do a local install and setup the hook by running ./node_modules/.bin/github-todos. Let me play around with that for a bit and I'll get back to you, but even if I get it working, I suspect there could be a use-case for decoupling the bash/githooks part from the actual github api/source code updating part.

[naholyr]

Sorry for the delay, holidays and whatnot.

My daughter is now 1 week old, oh how I forgive your delay :P

Ideally, it would run between steps 2 and 3 (if the tests pass).
For this use case, user interaction doesn't matter.

What will be missing then is an elegant way to disable user interaction. It's already packed in a separate module (lib/ask) that could be overriden for specific usages.

Options should not be hard to pass as parameter instead of reading from file, even if it's not your main issue here.

Local install will definitely do the trick anyway if you take care of disabling all interaction (+ DRY_RUN first days he ;))

[naholyr]

Is there more work to do here? 💃

[ianwremmel]

I still suspect it could be useful to separate out the parse/rewrite code from the actual githook part, but I don't have a specific need at the moment, so yea, I think this can be closed.