Additional hook types and information to expose

[dylanaraps]

• What information would you like exposed to hooks?
• Are there any other places in the package manager you would like to hook into?

[jedahan]

I will try and keep each feature request in a separate comment, so its easier to comment on.

---

I would like a post-update hook for repository pulls, with the following metadata

• The full path to the updated repository (e.g. /var/db/kiss/repos/kiss)
• The commit hash before update (e.g. 33d4f4)
• The commit hash after update (e.g. 123456)

Maybe the commit hash before update should be in a pre-update hook.

The use case would be for me to aggregate and show a summary of whats changed via git log, something like kiss-log.

[dylanaraps]

All you need is the full path. On pre-update you can grab the first hash and on post-update the second. The git commit information is nothing unobtainable outside of the package manager so I don't think it should expose it. ie, hash=$(git rev-parse HEAD).

Edit: The hook is executed in the git repository so PWD is the current repository which makes this easy.

[dylanaraps]

We need to also document the hook types and their arguments/environment so scripts know what they're given.

[dylanaraps]

Simplified the hook code further. Now supports any number of arguments to hooks (and the arguments are generic).

https://github.com/kisslinux/kiss/blob/master/kiss#L110-L119

[jedahan]

Nice! I have a sketch of a hook that uses this up https://github.com/jedahan/kiss-repo/pull/5/commits/7f317bff1356107cededb0969b816f678897adfe

#!/bin/sh -e

case $1 in
pre-update)
    git -C "$2" rev-parse HEAD | read -r _start
    ;;
post-update)
    git -C "$2" log --oneline HEAD..."$_start"
    ;;
esac

[dylanaraps]

You can just do:

case $1 in
pre-update)
    # This works as $PWD == $2.
    pre_hash=$(git rev-parse HEAD)
;;

post-update)
    git log --oneline "HEAD...$pre_hash"
;;
esac

The hook only executes once per git repository also. There's no need for you to filter any duplicates. We could omit passing an argument altogether documenting that the update hooks are executed in the repository itself.

[dylanaraps]

Hooks are documented here: https://kisslinux.xyz/package-manager#6.1

This should prevent misuse and add clarity. Closing this issue as I'm happy with how these are for now (and I want to push a release today).

We can expand this over time. I'm out of ideas for now anyway. ;)

Thanks for the help.