Refactorizar hooks

[jaimeph]

Añadir parámetros: dir_path, file_path, commit, tag, version Crear estructura para hooks. Darle una vuelta. pre-bump, ¿pre-project-bump?, ¿pre-tag-bump?, ¿pre-path-bump?, ... ¿pre-command-bump, post-comand-bump? ¿pre-bump, post-bump? pre-command-bump for projects verify-bump ¿parámetro bumpYes? pre-bump bump post-bump end post-comand-bump

[sergiotejon]

@jaimeph. esto aquí escrito en plan lluvia de ideas... Para dejarlo más claro, ¿podrías exponerlo de una forma un poco más clara? Gracias.

[jaimeph]

Por un lado sería, si sabemos el número exacto de hooks, creo que sería mejor, en vez de poner un Hooks map[string]string que pueda aglutinar cualquier cosa, definir una estructura con los distintos hooks. Ejemplo:

type Hooks struct {
   PreBump string
   PostBump string
..
}
type ConfigVersion struct {
...
   Hooks Hooks
}

Creo que quedaría más limpio y la llamada luego en vez de hacerla con un string:

err = config.RunHook("pre-bump")
        if err != nil {
            return []string{}, "", fmt.Errorf("pre bump scripts: %s", err)
        }

Hacerla mejor así o similar:

err = config.RunHook(config.Hooks.RunHook)
if err != nil {
    return []string{}, "", fmt.Errorf("pre bump scripts: %s", err)
}

El método config.RunHook ya no tiene sentido que esté asociado al objeto ConfigVersion y podría ponerse en un paquete distinto o en un archivo del paquete config distinto, tipo hooks.go (similar a find.go)

--

Luego añadiría un listado tipo (un ejemplo): pre-command-bump, check-bump, pre-bump, post-bump, post-command-bump

[sergiotejon]

Voy a abordar en primer lugar los 4 hooks que tenemos ahora mismo. Luego si eso discutimos si salimos así o dejamos para siguientes versiones nuevos hooks.

[sergiotejon]

Establecidos los 4 hooks desde una estructura. Se ha mantenido como métodos y se han asociado 4 métodos públicos funcionando como alias para los 4 eventos que hacen referencia, estableciendo runHooks como privados.