Git: gancho de pre-recepción con PHP_CodeSniffer

Desde que pasamos de SVN a Git, perdimos la capacidad de aplicar nuestros estándares de encoding a través de un pre-commit en el server de subversión.

Con Git, solo tienes ganchos de precompromiso en el cliente que no se pueden aplicar de ninguna manera. Lo que lo empeora es que tenemos desarrolladores que trabajan con los tres sistemas operativos principales, por lo tanto, un enlace precompromiso que funciona en Linux o OS X no funciona automáticamente en Windows.

El path a seguir es implementar un gancho pre-receive en el server, pero la solución no es tan fácil como parece:

Imagine que el desarrollador hizo 20 commits y quiere presionarlos. Todos los enganches de precompromiso y pre-recepción que conozco ( 1 , 2 ) solo comtestingn las confirmaciones únicas, que finalmente fallarán y evitarán el empuje. Ahora el desarrollador corrige los problemas y hace otro commit, e intenta presionar nuevamente. Como los ganchos comtestingn las confirmaciones únicas, fallarán nuevamente.

Por lo tanto, necesitamos un gancho de pre-receive que genere una list de todos los files modificados en todas las confirmaciones que se enviarán y ejecuta phpcs solo en el estado actual.

¿Ya existe ese script de anzuelo? ¿Dónde?

Editar: Parece que hay una secuencia de commands que crea esa list de files , desafortunadamente en Python, pero que puede ser portada. Todavía estoy interesado en soluciones prefabricadas con PHPCS 🙂

Preferiría no esperar un gancho del lado del server para controlar un empuje.

Puede configurar un repository intermedio que pueda get las twigs de cada desarrollador con mucha frecuencia y auditar cada compromiso nuevo, enviando un correo electrónico si un compromiso no cumple con algunos criterios pnetworkingefinidos.

También puede tener un gancho de pre-recepción en el repository central, pero al less el desarrollador sería consciente de un posible problema antes.

No creo que haya una solución técnica aquí, pero si realmente quieres molestar a la gente, entonces integra phpcs en tu configuration de CI y comienza a abrir tickets para ella en tu administrador de problemas. 😉

No creo que sea la mejor idea, porque realmente no es un problema técnico. Su problema no es un gancho previo o posterior a la confirmación, sino que las personas no lo hacen y cree que debe forzarlos.

En general, entiendo la importancia de un estándar de encoding y hago cumplir uno también, pero hay un componente social (o aspecto) de él.

Parece que las personas que trabajan con usted o no saben nada (todavía) o no desean aprender. Entonces, en caso de que no lo sepan, debes trabajar con ellos y enseñarles a cumplir con tus requisitos. Eso incluye enseñarles por qué las convenciones son importantes y, al final, deben entender que una característica no se hace hasta que todo esté verde.

Tal vez eso requiera que la gestión del proyecto (supongo que eres tú) descompone un problema en múltiples tareas hasta que lo obtengan:

  • característica en sí
  • phpcs
  • documentation
  • testings unitarias

(En ningún order específico; ;-))

Si no están dispuestos a aprender, siempre puedes tomar medidas más drásticas. Al igual, comenzaría lentamente y haría una revisión de performance semanal (situación 1-a-1) y reiteraría por qué no lo hacen. Si eso no ayuda, supongo que captarás mi deriva.

En el proyecto Drupal, hemos migrado recientemente a Git y estamos viendo problemas similares. En nuestro caso, no queremos que nadie revise un file LICENSE.txt para un module, ya que nuestros scripts de empaque lo hacen automáticamente. Después de algunos vaivenes, lo que se nos ocurrió fue un gancho de recepción que no rechaza un compromiso incorrecto, pero cada vez que detecta un compromiso incorrecto (para una definición de "malo") automáticamente presenta un error crítico en nuestro error rastreador. De esta forma, el código aún se confirma, pero tanto el responsable del module como el equipo de webmaster correspondiente son notificados inmediatamente de que algo va mal y debe corregirse. También podría enviar un correo electrónico o enviar un tweet o cualquier otra notificación que desee.

De hecho, aún no lo hemos implementado, pero ese es el plan en el que estamos trabajando tan pronto como nuestro equipo de implementación de Git tenga time. 🙂

Básicamente, no hay una buena solución para el problema que describes aparte de reformularlo; en lugar de "bloquear las violaciones detectables" se convierte en "informar violaciones detectables". Creo que es lo mejor que puedes hacer.

usa jenkins + gerrit:

http://alblue.bandlem.com/2011/02/gerrit-git-review-with-jenkins-ci.html

si tu construcción falla, el empuje será rechazado.

http://source.android.com/source/life-of-a-patch.html

Tyrael

No pronuncio un buen 'git-anese', pero en Mercurial hay una opción de gancho llamada 'changegroup' que esencialmente comtesting la confirmación 'superior' de un grupo de confirmaciones entrantes. Tal vez alguien en la comunidad pueda decirte si hay un equiv. de 'changegroup' para git?

https://www.mercurial-scm.org/wiki/Hook#The_changegroup_hook

Tal vez la respuesta a esta pregunta ayude? Gancho pre-recepción Git

Utilicé este enlace: http://criticallog.thornet.net/2011/06/02/running-php-linter-before-pushing-changes-to-a-git-repository/

y lo modifiqué para probar también el código con phpcs.

Puede contener algunos errores y he codificado el estándar de código drupal pero funciona. http://pastebin.com/fEmN519B

No tengo una respuesta exacta para esta pregunta directamente usando ganchos pre-commit / pre-recception, etc.

Me acerco a esto desde la otra dirección, ejecutando un server de CI, (yo uso jenkins) ejecutando phpcs y el complemento checkstyle para Jenkins.

Esto me permite fallar la compilation y enviar un correo electrónico al committer basado en el informe de estilo de control.

Opcionalmente, puedo establecer umbrales, de modo que obtengo una compilation inestable si hay hasta 5 nuevas infracciones de estilo pero una falla si se han comprometido más de 5.

También puedo establecer umbrales generales, por lo que más de 10 violaciones en todo el proyecto causan una falla y envía un correo electrónico al equipo.

Este podría ser su server intermedio como se mencionó anteriormente. Las acciones de compilation posteriores pueden include un empuje a otro repository de git.

Usamos un git wrapper (para replace los git-submodules con algo más sano para nuestros propósitos) y tiene el efecto secundario de configurar automáticamente los ganchos pre-commit automáticamente desde un directory mágico. Como se trata de un entorno empresarial, no hay quejas (y hay una manera de desactivarlo de todos modos).

He experimentado con esto también. No tengo el código a mano en este momento, pero utilicé uno de los ganchos (no pre-recibo, creo que fue el de actualización) para hacer un checkout temporal de la nueva reference. Puede acelerar esto teniendo un tree desprotegido que solo tiene que actualizar y simplemente haciendo clones superficiales.

Esto le permite acceder a todo el tree de fonts y no solo puede ejecutar CS en los files modificados con el command push, sino también ejecutar la unidad o las testings de detección de humo.

También estoy de acuerdo con algunos de los otros comentarios de que estas testings deben mantenerse al mínimo, porque nada es más molesto que estar bloqueado por commit hooks. Cualquier verificación adicional debería estar ocurriendo en su server CI o sistema de implementación.

Ahora empleamos ganchos de precompromiso que comtestingn el código y el post de confirmación.

Los desarrolladores pueden omitirlos con -n , pero rara vez lo hacen y siempre tenemos otro desarrollador haciendo control de calidad para que las cosas se noten.

El enganche es importante porque detecta cuando los files están rotos, de modo que PHP o JS rotos no se comprometen en absoluto.

Encuéntrelos enganchar código en https://github.com/netresearch/git-client-hooks

Usamos un server central para el desarrollo, y nuestros ganchos git se instalan automáticamente porque proporcionamos una plantilla central de repository de git que se usa automáticamente cuando git clone o git init .

¿Ya existe ese script de anzuelo? ¿Dónde?

Un método para ejecutar linters PHP usando git hooks ha sido puesto a disposition aquí: https://github.com/stevegrunwell/wp-enforcer

Verifique este proyecto: https://github.com/phpro/grumphp No puede instalar ganchos de pre-recepción, pero posiblemente resuelva sus problemas de anzuelos de precompromiso entre sistemas operativos cruzados.